> 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. > 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? > 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. Gordon
