Re: add support for STAILQ_* to queue.h
On 23/04/2020 16:18, Todd C. Miller wrote: On Thu, 23 Apr 2020 14:40:15 +0200, Denis Fondras wrote: I don't know if it is useful to anyone else but it is required by lsquic, a library that implements QUIC / HTTP3. sniproxy port also uses STAILQ_*, there is a patch in the port for the implementation. smime.p7s Description: S/MIME Cryptographic Signature
Re: add support for STAILQ_* to queue.h
On 2020/04/23 10:31, Theo de Raadt wrote: > Todd C. Miller wrote: > > > On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote: > > > > > My questions boil down to: > > > > > > 1) When are too many APIs too may? (It seems there is some agreement > > > already) > > > > > > 2) Is STAILQ more ubiqitous? (I suspect so) > > > > STAILQ is supported by: FreeBSD, macOS, NetBSD, Solaris, Linux (via libbsd) > > SIMPLEQ is supported by: NetBSD, OpenBSD, Solaris > > > > So based on a quick survey, STAILQ is more ubiqitous. > > > > > 3) Can upstream be convinced to use STAILQ instead? > > > > Upstream *is* using STAILQ, we're the ones who only support SIMPLEQ. > > > > Personally, I would rather replace SIMPLEQ with STAILQ in our code, > > though I suspect that is not a popular opinion here. When I see > > STAILQ I know exactly what it means and it is consistent with the > > other macros. I find that the SIMPLEQ naming conveys very little > > meaning and I always have to go check to see if it is singly or > > doubly linked. Of course, like most things, you get used to the > > way things are... > > I would be happy wit such unification. > > Are there any objectors? > > (finishing this might need to be put off for about a month, tho) > No objection, after we're done with release builds I can do a test ports build for this.
Re: add support for STAILQ_* to queue.h
On Thu, Apr 23, 2020 at 10:31:53AM -0600, Theo de Raadt wrote: > I would be happy wit such unification. > > Are there any objectors? > > (finishing this might need to be put off for about a month, tho) > I am currently building base with a diff that converts SIMPLEQ_* to STAILQ_*
Re: add support for STAILQ_* to queue.h
Todd C. Miller wrote: > On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote: > > > My questions boil down to: > > > > 1) When are too many APIs too may? (It seems there is some agreement > > already) > > > > 2) Is STAILQ more ubiqitous? (I suspect so) > > STAILQ is supported by: FreeBSD, macOS, NetBSD, Solaris, Linux (via libbsd) > SIMPLEQ is supported by: NetBSD, OpenBSD, Solaris > > So based on a quick survey, STAILQ is more ubiqitous. > > > 3) Can upstream be convinced to use STAILQ instead? > > Upstream *is* using STAILQ, we're the ones who only support SIMPLEQ. > > Personally, I would rather replace SIMPLEQ with STAILQ in our code, > though I suspect that is not a popular opinion here. When I see > STAILQ I know exactly what it means and it is consistent with the > other macros. I find that the SIMPLEQ naming conveys very little > meaning and I always have to go check to see if it is singly or > doubly linked. Of course, like most things, you get used to the > way things are... I would be happy wit such unification. Are there any objectors? (finishing this might need to be put off for about a month, tho)
Re: add support for STAILQ_* to queue.h
On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote: > My questions boil down to: > > 1) When are too many APIs too may? (It seems there is some agreement already) > > 2) Is STAILQ more ubiqitous? (I suspect so) STAILQ is supported by: FreeBSD, macOS, NetBSD, Solaris, Linux (via libbsd) SIMPLEQ is supported by: NetBSD, OpenBSD, Solaris So based on a quick survey, STAILQ is more ubiqitous. > 3) Can upstream be convinced to use STAILQ instead? Upstream *is* using STAILQ, we're the ones who only support SIMPLEQ. Personally, I would rather replace SIMPLEQ with STAILQ in our code, though I suspect that is not a popular opinion here. When I see STAILQ I know exactly what it means and it is consistent with the other macros. I find that the SIMPLEQ naming conveys very little meaning and I always have to go check to see if it is singly or doubly linked. Of course, like most things, you get used to the way things are... - todd
Re: add support for STAILQ_* to queue.h
Todd C. Miller wrote: > On Thu, 23 Apr 2020 08:35:38 -0600, "Theo de Raadt" wrote: > > > SIMPLEQ arrived in 1997. Didn't it go to other systems? Did others > > invent STAIL on their own? > > FreeBSD added STAILQ (along with SLIST) in 1996. My questions boil down to: 1) When are too many APIs too may? (It seems there is some agreement already) 2) Is STAILQ more ubiqitous? (I suspect so) 3) Can upstream be convinced to use STAILQ instead?
Re: add support for STAILQ_* to queue.h
On Thu, 23 Apr 2020 08:35:38 -0600, "Theo de Raadt" wrote: > SIMPLEQ arrived in 1997. Didn't it go to other systems? Did others > invent STAIL on their own? FreeBSD added STAILQ (along with SLIST) in 1996. - todd
Re: add support for STAILQ_* to queue.h
Denis Fondras wrote: > On Thu, Apr 23, 2020 at 08:18:16AM -0600, Todd C. Miller wrote: > > Singly-linked tail queues are functionally equivalent to the "simple > > queues" we already have. Do we really need two implementations of > > what are effectively the same thing or should we just define STAIL_* > > in terms of SIMPLEQ_* and add any missing macros? > > > > Oh! Let's try that :) > Thank you Todd. SIMPLEQ arrived in 1997. Didn't it go to other systems? Did others invent STAIL on their own? Isn't some kind of convergence possible, rather than "two macros sets"?
Re: add support for STAILQ_* to queue.h
On Thu, Apr 23, 2020 at 08:18:16AM -0600, Todd C. Miller wrote: > Singly-linked tail queues are functionally equivalent to the "simple > queues" we already have. Do we really need two implementations of > what are effectively the same thing or should we just define STAIL_* > in terms of SIMPLEQ_* and add any missing macros? > Oh! Let's try that :) Thank you Todd.
Re: add support for STAILQ_* to queue.h
On Thu, 23 Apr 2020 14:40:15 +0200, Denis Fondras wrote: > I don't know if it is useful to anyone else but it is required by lsquic, a > library that implements QUIC / HTTP3. Singly-linked tail queues are functionally equivalent to the "simple queues" we already have. Do we really need two implementations of what are effectively the same thing or should we just define STAIL_* in terms of SIMPLEQ_* and add any missing macros? - todd
