Darren Reed writes:
> I think you've read what I wrote incorrectly.
I don't think so.
> I don't think that engineering should be (or is) more constrained
> but rather that it has a greater responsibility to provide easy to
> use interfaces that are useful to discourage others from reading the
> source code to find out how Sun does things (and thus copies our
> use of private interfaces) or looking through the source code to see
> if there is some undocumented function that does X and uses it.
> This is perhaps more likely to be an open source problem (:-) than it
> is for vendor products, but Solaris can no longer claim to be above
> those issues.
That's precisely what I read from your previous message, and it is
precisely the set of assertions with which I disagree.
Reading through the source and finding interesting-looking functions
without bothering to figure out whether the designer of those
functions _intended_ for you to use them, or at least asking that
designer to make those functions available for you, is not sound
engineering. It results in fragile and unsupportable software, and it
really doesn't matter how or why it happens.
That's no more or less true for other Sun products or proprietary
third-party products than it is for open source products. It doesn't
actually matter what sort of development model is used. To me, and I
suspect for many other ARC members as well, there's a big difference
between intentional and reliable design, and outright hackery.
That's not to say that hackery doesn't have its place in the world.
In a crisis situation, it of course must happen. But products that
are designed in a crisis situation are nearly by definition not good
ones, and we aim to produce good ones. That necessarily requires
communication between those providing interfaces and those using them,
and that communication is the foundation of the ARC.
This is exactly the issue that the architectural review process
addresses for Solaris (and at Sun in general). When someone designs a
subsystem (such as Nemo), he has to make promises about what sorts of
usage he will and will not support. Those things he promises to
support are the ones that others can use safely (within some defined
bounds). Those that aren't are just implementation artifacts. The
fact that someone else can possibly discover them through means other
than documentation, such as nm, grep, ksyms, or groveling through the
source itself, is immaterial.
The issue you're addressing -- the tension between allowing software
developers to have fluid internal interfaces so that implementation
can be refined over time without breaking other components, and
exposing the right set of stable interfaces for others to depend on --
is an old one. It's something that the ARC addresses every day, and
that every competent project team must face. It's a non-trivial basic
engineering decision, and not something that can just be waved away as
something that somehow magically goes away because of "open source."
> Back to more mundane matters, advice on how to approach the ARCs
> (are there others besides PSARC that are important here?) in order
> for them to take the API problem more seriously and get more projects
> to consider a path to "stable" (rather than stop with *.Private)
> would be appreciated.
I also reject that implication. The ARC most *definitely* takes
stability seriously.
I think you might be suggesting that the ARC should start forcing
project teams to make things more stable than they actually are. That
is *EXACTLY* what I meant about constraining engineering efforts.
Such an action would force some project teams into a serious problem:
either ship early and give customers things they want but forever
cement implementation artifacts into the supported system features, or
delay shipment indefinitely until the implementation artifacts can be
refined into a supportable interface.
We (in the ARC) of course address stability. If you listen to just
about any review, you'll hear discussion about what stability levels
are required and what those imply for software that may depend on the
project. And when the consumers require higher stability for the
project to be at all useful, we already do force projects to provide
that stability. This already happens, and has happened continuously
over the 15 year history of the ARC at Sun, so I just do not
understand what you could mean by asking us to take it "more
seriously."
For the general problem, the right thing to do is as I suggested
before: take the issue up with individual project teams that own
particular interfaces you're interested in (the Nemo team owns the
Nemo interfaces, not the Clearview team), Solaris management and the
PAC (they're the ones who fund the folks who would doing the work
you're requesting -- and, yes, raising stability levels does require
_work_), or the Tonic team (who are responsible for issues relating to
changes brought about by Open Solaris).
Perhaps you just disagree with the ARC's decision that Consolidation
Private was acceptable for Nemo, even given that both GLDv2 and DLPI
are supported interfaces for network drivers and thus Nemo is not
necessary for non-ON drivers. That's fine. You have at least two
useful courses of action on that one issue:
- Get in touch with those who support Nemo (I believe they're in
your group) and ask them to raise the stability level of those
interfaces and document them for use outside of ON.
- File an appeal to the ARC decision. That process is documented
here:
http://sac.sfbay/arc/Processes/Member.Handbook/appeals.txt
(There's a step short of an appeal: you could ask the ARC informally
to reconsider its decision, but I very much doubt that'd be effective
in this particular case.)
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
