James Carlson wrote:
Andrew Gallatin wrote:
James Carlson wrote:
I don't believe I have made that assumption. Mostly because I believe
the opposite: it's hard to get into ON. And that's not all a bad thing.
Except when the process to get a driver integrated to ON is so byzantine
that it drags on for literally *YEARS* in some cases. Combine that
with the fact that many of the decent driver interfaces are
consolidation private, and you condemn ON to a dearth of driver
support. If GLDv3 and the sound interfaces were made stable,
a lot of this would go away.
Indeed!
But the proposal under consideration doesn't actually address those
problems. It provides you yet another place to put your sources, but
one in which the sources will _still_ not be kept up-to-date with
respect to private interface changes, such as those in GLDv3. It's
still a backwater, and does not have the helpful burdens of ON: when
changes happen, nobody's going to update your source to conform.
No, the proposal was for build-for-build compat with ON.
As it is today, ON has the major drawback of Linux
(volatile interfaces that prevent shipping a binary) without
the benefit (ease of integration) from an IHVs perspective.
Actually, you do have at least two supported and stable interfaces for
integrating new Ethernet drivers: GLDv2 and DLPIv2.
That they provide less functionality and performance than some users
might like is certainly a defect, and the fact that the long-proposed
replacement isn't yet stable enough to be public is a real shame, but
it's certainly _not_ the case that this means Solaris has the same Linux
drawbacks. It only seems that way if your code is dependent on GLDv3
and (for whatever reason, including performance) you're unwilling to
work with the alternatives.
GLDv2 doesn't even offer LSO. It is laughable. Especially
since v2 could be easily extended to support LSO. GLDv2
is just not a realistic option to expect anybody to use
these days.
Hell, you can't even ship *SOURCE* and expect a user to build it
because the non-stable interface header files are not published
outside the HG tree. At least on Linux, you can ship source
and have a reasonable expectation that a user can compile your
driver.
Even if the headers were shipped, they'd do you no good. You'd still
end up with binaries that sometimes roach the system, or, if you're
lucky, sources that fail to compile at all across software updates.
Not if you put a bit of common sense into it, and installed modules
using private interfaces into a private, kernel-version specific
place. Its not hard. Linux does it (/lib/modules/2.6.31/...).
FreeBSD does it (/boot/kernel/... with 3rd party drivers using stable
interfaces in /boot/modules). Linux even has a mechanism (dkms)
to re-build 3rd party modules automatically at boot time when
the kernel is updated.
That's the bad thing about private interfaces, particularly when used in
areas where public interfaces are really required.
Fixing that defect seems like a very important goal -- far more
important than much else that's likely being done now -- but I don't see
this proposal helping in any notable way.
If it provided a place where build-for-build binaries were generated,
it would help immensely.
Drew
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
