Gordon Ross wrote:
>> Okay, but all of *those* comments are *not this case*. Unless someone
>> believes this case ought to be abandoned in favor of the queue.h macros.
>>
>
> I did not intend to suggest that. Having both is OK.
> Just document which is preferred when and why.
> (Solaris value add vs portability)
>
>
>> For my nickel, I think its sad that we have to have two "competing" list
>> types in the kernel. Converting queue.h into list.h (or vice versa) is
>> such a trivial task that it should never take an engineer more than a
>> little bit of time. Compared to the major effort to port a device
>> driver from one OS to another (and you might say I know just a little
>> bit about what's involved there!), dealing with the list handling stuff
>> is just minor noise.
>>
>
> While it may seem trivial to you, it may not always be desirable.
> The code I spend most of my time in uses <sys/queue.h> and I've
> kept it to reduce differences from other ports of the code.
>
Ok. Although, as I said, I've found that this is one of the areas of
code where the differences matter the *least*, at least in the various
device drivers I worked with.
>
>> 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.
>>
>
> You're not making that part of this case, right?
>
No. Jim Carlson has raised the point that this header is used in
*userland* code. Ugh.
>
>> Driver developers that *really* want to use queue.h are of course free
>> to import private copies of that header file into their own source code,
>> although I wish we saw less of that inside ON.
>>
>
> I assume someone integrated <sys/queue.h> because they were
> tired of dealing with N private copies of it scattered around.
>
Possibly. However, in that case it *ought* to have been properly ARC'd,
and an interface stability granted to it.
- Garrett
