Support enabling debugging macros for userland and _STANDALONE builds,
in addition to the already existing kernel support. On runtime error,
panic() is used for kernel and _STANDALONE builds, and a simple
fprintf() + abort() combination for userland ones. These can be
overriden if needed by defining the QMD_PANIC() and/or QMD_ASSERT()
macros.
The expansion of queue debug macros can now be controlled more finely
thanks to the QUEUE_MACRO_DEBUG_ASSERTIONS and
QUEUE_MACRO_NO_DEBUG_ASSERTIONS macros. The first one serves to
forcibly enable debug code and the second to forcibly disable it. These
are meant to be used as compile options only, and should normally not be
defined in a source file. It is an error to have both of them defined.
If none of the two above-mentioned macros are defined, an automatic
determination is performed. When compiling kernel code,
QUEUE_MACRO_DEBUG_ASSERTIONS is defined if INVARIANTS has been defined
(as before). For userland and _STANDALONE builds, no debug code is ever
automatically inserted even if NDEBUG is not defined, as doing so would
inflate code size and users may want to have working assert() calls
without this overhead by default.
In the manual page, document check code control under DIAGNOSTICS.
While here, rework a bit the rest of the DIAGNOSTICS section.
Reviewed by: markj (older version)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49973
(cherry picked from commit 1c5fea9e8b)
*_SPLIT_AFTER() allows to split an existing queue in two. It is the
missing block that enables arbitrary splitting and recombinations of
lists/queues together with *_CONCAT() and *_SWAP().
Add *_ASSERT_NONEMPTY(), used by *_SPLIT_AFTER().
Reviewed by: markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49608 (stailq)
Differential Revision: https://reviews.freebsd.org/D49969 (rest)
(cherry picked from commit c028802339)
In some places, these macros are used without a lock, under the
assumption that they are naturally atomic. After commit
34740937f7 ("queue: New debug macros for STAILQ"), this assumption is
false.
Provide *_EMPTY_ATOMIC for such cases. This lets us include extra debug
checks for the non-atomic case, and gives us a way to explicitly
annotate unlocked checks, which generally deserve extra scrutiny and
might otherwise raise reports from KCSAN.
Reviewed by: kib, olce (previous version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48899
(cherry picked from commit d2870b8666)
to the traditional tree(3) RB trees, but using an array (preallocated,
linear chunk of memory) to store the tree.
This avoids allocation overhead, improves memory locality,
and makes it trivially easy to share/transfer/copy the entire tree
without the need for marshalling. The downside is that the size
is fixed at initialization time; there is no mechanism to resize
it.
This is one of the dependencies for the new stats(3) framework
(https://reviews.freebsd.org/D20477).
Reviewed by: bcr (man pages), markj
Discussed with: cem
MFC after: 2 weeks
Sponsored by: Klara Inc, Netflix
Obtained from: Netflix
Differential Revision: https://reviews.freebsd.org/D20324
Split the QUEUE_MACRO_DEBUG into QUEUE_MACRO_DEBUG_TRACE and
QUEUE_MACRO_DEBUG_TRASH.
Add the debug macrso QMD_IS_TRASHED() and QMD_SLIST_CHECK_PREVPTR().
Document these in queue.3.
Reviewed by: emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D3984
queue.h header file and in the queue.3 manual page that they are O(n)
so should be used only in low-usage paths with short lists (otherwise
an STAILQ or TAILQ should be used).
Reviewed by: kib
adding macros to define class lists.
This change is backwards compatible for all use within C and C++
programs. Only C++ programs will have added support to use the queue
macros within classes. Previously the queue macros could only be used
within structures.
The queue.3 manual page has been updated to describe the new
functionality and some alphabetic sorting has been done while
at it.
Differential Revision: https://reviews.freebsd.org/D2745
PR: 200827 (exp-run)
MFC after: 2 weeks
optionally start the traversal from a previously found element by passing the
element in as "var". Passing a NULL "var" retains the same semantics as the
regular FOREACH macros.
Kudos to phk for suggesting the "FROM" suffix instead of my original proposal.
Reviewed by: jhb (previous version), rpaulo
MFC after: 1 week
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
Last year I added SLIST_REMOVE_NEXT and STAILQ_REMOVE_NEXT, to remove
entries behind an element in the list, using O(1) time. I recently
discovered NetBSD also has a similar macro, called SLIST_REMOVE_AFTER.
In my opinion this approach is a lot better:
- It doesn't have the unused first argument of the list pointer. I added
this, mainly because OpenBSD also had it.
- The _AFTER suffix makes a lot more sense, because it is related to
SLIST_INSERT_AFTER. _NEXT is only used to iterate through the list.
The reason why I want to rename this now, is to make sure we don't
release a major version with the badly named macros.
Even though single linked lists allow items to be removed at constant time
(when the previous element is known), the queue macro's don't allow this.
Implement new REMOVE_NEXT() macro's. Because the REMOVE() macro's also
contain the same code, make it call REMOVE_NEXT().
The OpenBSD version of SLIST_REMOVE_NEXT() needs a reference to the list
head, even though it is unused. We'd better mimic this. The STAILQ version
also needs a reference to the list. This means the prototypes of both
macro's are the same.
Approved by: philip (mentor)
PR: kern/121117
cd src/share; find man[1-9] -type f|xargs perl -pi -e 's/[ \t]+$//'
BTW, what editors are the culprits? I'm using vim and it shows
me whitespace at EOL in troff files with a thick blue block...
Reviewed by: Silence from cvs diff -b
MFC after: 7 days
