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
