James Carlson wrote:
> Garrett D'Amore wrote:
>
>> Gordon Ross wrote:
>>
>>> Are the <sys/list.h> types and functions used on any other systems?
>>> Or something similar? Or would this be Solaris-specific?
>>>
>>> The one I've most often run across on other systems is the
>>> BSD-style <sys/queue.h> (which Nevada has now).
>>>
>>>
>> Wow. I didn't even know that queue.h was present. However, it is also
>> not covered by any ARC case.
>>
>
> I thought it was fwflash ... but my memory is fading. I know it was
> talked about before.
>
>
>> I really, really wish CRTs and project teams would pay closer attention
>> and not *deliver* header files into SUNWhea which are intended for
>> internal (Consolidation Private or Project Private) use only.
>>
>> Anyway, these list functions would be Solaris-specific.
>>
>> The BSD queue functions, while richer, actually are defined as macros,
>> so there isn't really a binary compatibility concern when using them.
>>
>
> That part's not true. Macros actually have substantially worse binary
> compatibility issues to deal with: the macro itself and all data
> structures that it references simply can never change at all in any way.
>
This is true when the macro is used to reference binary structures from
one binary object in another.
> Remember the fileno() fiasco? At least with functions, we have symbolic
> tricks we can pull to get different (and compatible) behaviors depending
> on who calls the function and how it's called.
>
> Fortunately for the BSD queue macros, that really isn't an issue. They
> haven't changed in approximately forever.
>
More to the point, the "macros" for the BSD queues are self-contained.
That is to say, assuming you only use the macros within a single module,
and not to access queues built into another binary object, then you are
pretty much guaranteed that the results will be safe. (I.e. if you
only use them to create and manage driver-private linked lists, then you
will be safe.) This is because all of the possibly volatile bits of the
implementation are actually compiled into the consumer itself, rather
than residing someplace else where change can result in breakage (e.g.
genunix).
That said, I prefer the Solaris versions if only because the
*implementation is not shared. While it means that there is function
call overhead, at least the code in genunix won't be duplicated,
resulting in hotter caches, and smaller binaries.
Plus it allows for possible change. In theory, someone could, for
example, add a locked initialization variant to these, so that the
functions could be used with a lock that protects the list linkage itself.
- Garrett
