Christian Weisgerber <[email protected]> wrote:
> Theo de Raadt:
>
> > What is lacking in this converstation is the justification.
> > Why?
>
> Providing STAILQ in OpenBSD will simplify porting to OpenBSD.
> (Reality check: There is one port affected by this.)
>
> Switching OpenBSD to STAILQ will simplify porting from OpenBSD.
> (There are three or four FreeBSD ports affected by this.)
>
> Having both SIMPLEQ and STAILQ will cause no disruption, but means
> providing two APIs that are identical except for their name.
Yes, perhaps both are needed for a time, and later steps can decide
the right path.
However until that decision is made, these field renames seem unwelcome.
They are not completely hidden, and may become exposed in API or ABI
somewhere.
/*
- * Simple queue definitions.
+ * Singly-linked tail queue definitions.
*/
-#define SIMPLEQ_HEAD(name, type) \
+#define STAILQ_HEAD(name, type)
\
struct name { \
- struct type *sqh_first; /* first element */ \
- struct type **sqh_last; /* addr of last next element */ \
+ struct type *stqh_first; /* first element */ \
+ struct type **stqh_last; /* addr of last next element */ \
}
-#define SIMPLEQ_HEAD_INITIALIZER(head) \
- { NULL, &(head).sqh_first }
+#define STAILQ_HEAD_INITIALIZER(head) \
+ { NULL, &(head).stqh_first }
-#define SIMPLEQ_ENTRY(type) \
+#define STAILQ_ENTRY(type) \
struct { \
- struct type *sqe_next; /* next element */ \
+ struct type *stqe_next; /* next element */ \
}
