James Carlson wrote:
Darren Reed writes:
...
Now that solaris is open, we need to be making more effort
to provide good stable interfaces for developers at all levels
to work with so that they aren't encouraged to read source
code and use interfaces that will cause them pain in the future.
That sounds like a different sort of argument to me, and probably
something you should direct to the Tonic team or the PAC instead.
The implication is that open-sourcing the software means that
engineering, now both inside and outside of Sun, is constrained in
ways that it had not been in the past. It means that where we once
used to draw a clear distinction between "visible but you shouldn't
use" (denoted "Private" in the taxonomy) and "visible and we want you
to use" (denoted "Public"), we no longer have that flexibility.
I don't believe I agree with that argument. We should certainly be
providing outside developers access to much more than just the source
itself, and I believe that we are actively attempting to do so. We
should provide more internal documentation on the design of the system
itself. The code alone is nearly useless without it.
I think you've read what I wrote incorrectly.
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.
As an example of what we shouldn't do is take the GSSAPI approach.
Try writing a program with the GSSAPI just to change or set your
password.
If I wanted to write a new virtual NIC for Solaris, what approach
would I take? If I want to make a new NIC to experiment with a
protocol like CARP or VRRP, where would I go for how to start on
such a project? Do we have sufficient interfaces to support this?
Do I have to write a complete NIC driver, like a bge, even though
gld is available, or can we make something else, better? Ideally
I'd expect the IPMP code to be a model of how to do this.
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.
(The only stability level that seems threatened in this brave new
world is "Sun Private." That particular stability level was
effectively "actually Stable but we're not funded to write a man
page," and thus was fairly strongly discouraged. Maybe we can hammer
the last nail in that particular coffin.)
I'm all for doing that to this particular category.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
