Garrett D'Amore wrote:
> My brief comments:
>
> 1) We need a list API.
Agreed.
> 2) I'm of the opinion that having multiple APIs in the DDI to accomplish
> the same thing is not constructive.
It's certainly suboptimal. But where there are two or more important
and conflicting traditions, what do you do?
> 3) <sys/queue.h> should never have been delivered in SUNWhea without a
> supporting ARC case. (But then neither should have sys/list.h.)
I disagree with that assertion. The contents of SUNWhea is not itself a
documented interface -- in other words, what determines stability level
is system documentation (man pages), and not what package delivers
something or where it appears in the file system.
We have historically shipped a mix of public and private interfaces via
SUNWhea. Long ago, I filed a CR (forget the number) that suggested
breaking up SUNWhea (and the SUNWarc* and perhaps other) package into
public and private bits, so that we could install only public interfaces
by default, and exclude private ones from accidental discovery.
(Obviously, users who need to can always install the private packages;
we'd still ship them -- perhaps with even more things included -- but
just not install by default.)
Think of it as linker mapfiles for packaging. The idea, unfortunately,
went nowhere. Too many people were either skeptical of the utility of
breaking up SUNWhea or of the value of trying to segregate private
interfaces better.
In this case, sys/list.h was Consolidation Private and sys/queue.h was
(apparently) intended as Project Private but somehow used as though it
were Consolidation Private. In any event, those sorts of interfaces do
not *necessarily* need ARC review.
Though I agree that some ARC review would have been better than not
having it at all.
> 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.
No longer a member, but I think that completely misses the point.
The point is:
- go ahead and add stable support for <sys/list.h>; we need it.
- leave <sys/queue.h> where it is; the world needs it.
- someone (not necessarily you) should provide a case that
documents <sys/queue.h>, because it clearly slipped through
the process cracks.
- these things are unrelated. Really.
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
