My brief comments:
1) We need a list API.
2) I'm of the opinion that having multiple APIs in the DDI to accomplish
the same thing is not constructive.
3) <sys/queue.h> should never have been delivered in SUNWhea without a
supporting ARC case. (But then neither should have sys/list.h.)
4) I'm not interested in comparing sys/list.h vs. sys/queue.h. I have
my opinions, and a big discussion will just degenerate into bikeshedding.
5) If a Member feels that sys/queue.h is preferable to sys/list.h, then
I think that Member should derail this case (at which point I'll
probably just withdraw it) and then we can try to identify a list
interface that is best suited for the DDI.
-- Garrett
Darren Reed wrote:
> On 8/09/09 10:55 AM, Garrett D'Amore wrote:
>> James Carlson wrote:
>>>
>>>> Given that, I'd actually prefer to remove the queue.h interfaces, and
>>>> promote list.h. list.h interfaces are safer than BSD queue.h (see
>>>> above
>>>> argument), and have been around and available since ~forever.
>>>>
>>>
>>> Please don't!
>>>
>>> The BSD queue.h interfaces are used in both kernel *and* user-space
>>> code
>>> -- they're also present on Linux -- and the lack of them on classic
>>> Solaris is a very annoying application portability issue.
>>>
>>> Removing them would be a big step backwards.
>>>
>>>
>>
>> Ok. Well in this case, someone else should raise the commitment
>> level and ARC them. Just having them "appear" on Solaris without any
>> ARC coverage or interface stability is IMO less than helpful.
>>
>> It looks like this arrived with the Packet Filter Hooks stuff.
>
> Because that was the easiest way to get it in. At the time there was
> both programming desire and portability concerns and I was not
> interested in the "lengthy discussion" that would likely ensure on the
> PSARC mailing list if I tried to them introduced as a stable interface.
>
> With the "new and improved" PSARC, maybe it would be an easier
> task to raise their commitment level now.
>
> But now that the topic has been brought up, maybe sometime soon
> would be appropriate...
>
> btw, the <sys/list.h> interfaces are only "safer" in some respects:
> for example, they're less safe with types. The <sys/queue.h> interfaces
> all require explicit types be used for every structure. You cannot
> easily insert something of "type a" into a list of "type b". With
> the gratuitous use of "void *" in <sys/list.h>, simple protection such
> as this is non existent.
>
> Personally, I prefer the <sys/queue.h> interfaces for another reason:
> when you're choosing a "type of list" to store data in, you need to
> make a conscious choice about whether it is a linked listed, tailq,
> circular queue, etc. IMHO, this plays an important role in how
> you manage the data and especially for how others view the code
> later. Whilst <sys/list.h> is more flexible like that, I think it
> opens up more risk by allowing one programmer to use it as
> a list and someone else to expect it to be a circular queue
> because the way data is organised may differ significantly.
> But this is just an opinion.
>
> Both interfaces suffer from other issues, such as if a data structure
> is common to more than one module and the location of the list
> data elements change in the structure, only updating one module
> is likely to cause problems. But this is a generic C problem.
>
> Whilst with <sys/list.h>, any change to list_t or list_node_t requires
> that all of code using that interface needs to be updated, with the
> <sys/queue.h> model, only "matching binaries" need to be updated.
> I'm not really worried about this, for two reasons:
> - the core data structures are very stable, it has been more common
> for newer list types to be added than the structures updated;
> - if/when they do change, it is likely to be a significant flag day.
> (both reasons apply to both sets of interfaces.)
>
> I suspect that any change to the internal structures would draw a lot
> of attention, even if it were "to provide locked(safe) API" as the
> seemingly better alternative would be to just build a complete new
> set of macros/functions that used their own data structures, rather
> than impose a new operational paradigm on code that doesn't have
> any need for it.
>
> So the only significant difference that I'm aware of is that the
> <sys/queue.h> interfaces offer type safety whereas the one in
> <sys/list.h> does not. For some people this might be important,
> for others not.
>
> Darren
>
