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. > 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. > 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. 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. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
