Andrew Gallatin wrote: > James Carlson wrote: >> 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.
The folks doing the Nemo changes will not visit this new consolidation and update your driver for you. If your driver is part of ON, they'll be _forced_ to update any drivers that are affected. If it's not, then they're not compelled in any way. So who does that work of keeping all the drivers up to date with the latest Nemo changes? If it's the consolidation maintainers, then bully for them. They're making a huge commitment. If it's the driver authors, then I don't see how it's different from shipping your driver source on your own web site. Except, perhaps, that it's a little less convenient. >> 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. I'm sure your driver needs LSO, as do some others. That doesn't mean every driver does. I think my point was missed. >>> 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 just moves the problem to another module. Who maintains that? If it's not the people making changes to the Nemo bits, then we're back where we started. If it is, then putting that module into ON and having it maintained properly would be the best answer. Maybe it's "the" answer for Nemo. (Though it does beg some questions.) >> 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. You can do that today with wget+make. It doesn't have the other important attributes of a consolidation -- namely, the oversight. -- 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
