James Carlson wrote:
Darren Reed writes:
...
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 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.
Agreed.
...
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."
I don't think it goes away because of "open source", if anything it
becomes more acute. With, Nemo, for example, we introduce a new way
for Solaris network interface drivers to be written that is not
available to 3rd party network interface driver development.
While in the past this might have been concealed, open source makes
it easy for 3rd party developers to see what the difference is.
How do we encourage 3rd party developers to target Solaris if
we are using superior interfaces (for performance) than the ones
they are able to use? Is it ok to set double standards like this?
Or should we be forcing our own development to use the same set of
interfaces as external people can and create a level ground for
competition?
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.
Using the word "forcing" is too strong for what I had in mind, but being
more encouraging of continued effort on interfaces to ensure that they go
from being *.Private to Stable. Although I recognise this is a bigger
problem than just at the ARC level and I do want to get more involved
and learn more about how the ARCs work.
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."
In general, yes, you are right. There's a wealth of information and
interfaces available in Solaris that make most things easy - except
for networking. When I look at the manual pages in section 9, there
has been very little there apart from STREAMS message manipulation
until gld was introduced.
...
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:
...
I think trying to change history is not as useful as trying to shape
the future so asking the ARC to revisit its decision is not the way
I would approach the problem.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
