James Carlson wrote:
Garrett D'Amore wrote:
1) Currently GLDv3 exports DLPI style 2 nodes, as does GLDv2. I think
this adds complexity, and ultimately I think everyone would be better
served if we could eliminate this. I'd like to propose EOF'ing the
export of DLPI style 2 from GLDv3 (and incidentally from softmac.)
What would be the point? We would never be able to remove the feature,
as there's a fair amount of third-party code that relies on it, and as
DLPIv2 Style 2 is actually a standards-compliant interface. Sun (at
least in the past) has been rather hesitant to discard fundamental
standards.
DLPI style 2 is standards conformant, but DLPI style 1 is also part of
the same standard. Standards conformant programs are required to test
both DLPI style 1 *and* style 2. This is true with vanity naming anyway
-- Vanity names don't work with programs that *only* support style 2.
For an arbitrary example (pulled up by google), check out this function:
http://svn.dd-wrt.com:8000/dd-wrt/browser/src/router/pppd.new/pppd/sys-solaris.c?rev=7630#L2215
What makes it doubly weird is that for a very long time, the *only* sort
of interface supported on Solaris was in fact Style 2. All the old
"le"-derived interfaces were Style 2 only, and it was such a common
thing on Sun platforms that everyone (outside of Sun) *assumed* that
Style 2 was the expected norm. Style 1 is relatively newfangled and, in
the field, still extremely rare compared with Style 2.
That leaves you with only a worry-producing EOF notice, and no actual
removal. Why bother? The EOF notice itself won't help the code much,
will it?
It will simplify GLDv3 and softmac a fair bit, yes. (If we were able to
actually *remove* the code in the future.)
It will make sure that developers are *not* relying *solely* on style 2
to access the network devices. (Indeed, they should be using libdlpi,
but even if they don't, they need to at least start by trying a style 1
open first.)
2) Support for DLPI based ethernet device drivers. Right now we have
one major hold out (ce), which we *could* fix, but even if we don't
*remove* the DLPI interfaces in softmac, once GLDv3 becomes a public
interface, I think we ought to make the legacy GLDv2 and DLPI methods as
Obsolete. Eventually it might even be possible to remove them, either
by updating the existing drivers, or by EOF'ing the final hold outs.
How do you EOF third party drivers?
Not sure that there are any 3rd party pure DLPI drivers that are
concerning here. Most (all?) of the 3rd parties are on-board with GLDv3
these days. (I'm not sure about Fujitsu, but I'm sure we could work
with them.) ce is the *main* hold out here. (There are a few others --
"idn" used on E10K, and dman on starcat. dman is really just a variant
of eri, anyway.)
You will in fact need a Major release boundary (in that future day) in
order to remove an in-use standards-compliant interface.
Maybe... but we've already shown that there is flexibility here. We've
also already reached the point where if a driver developer wants to take
full advantage of Solaris' networking features, they really *do* need to
supply a GLDv3 driver. Pure DLPI drivers are treated as very distant
2nd or 3rd class citizens in Solaris, already.
Eventually I'd like to remove DLPI style 2 altogether, but from what I
can tell, it is still crucially used with ppp where the instance (PPA)
is created on demand in response to DL_ATTACH_REQ. I don't have a good
answer for that kind of usage.
Nor do I. It's currently much simpler than the sort of gyrations that
would be needed to make Style 1 work, and given that the differences
between the two styles are mostly trivial and related just to
open()-time messaging, it's hard to see why we'd want to care enough to
kill Style 2.
The proposal wasn't to kill all use of Style 2. The proposal was to
kill the guarantee that *all* drivers provide (via GLDv3) style 2. If a
pure DLPI driver wants to supply style 2, fine. But consumers *need* to
be smart enough to check for style 1. Then we can stop going through
the gyrations required to support style 2 in our drivers when really all
they ought to need to do is supply style 1.
- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
