> > I'm not sure I see exactly how this will work out as painlessly as you > > say, so let me describe my understanding of the situation and you can > > correct my mistakes. > > > > Let's suppose we want to continue to ship out-of-tree as well as > > in-tree drivers. The in-tree drivers are live in a single upstream > > codebase. This codebase can only produce working drivers for the > > kernel it ships. The out-of-tree drivers live in a single "downstream" > > codebase littered with compatibility wrappers as we do today. This > > codebase can be compiled for virtually any kernel, provided we > > continue to chase down all kernel API changes and wrap them. > > The problem is you are wanting to continue to maintain and support this > "downstream" codebase. If you drop that, it will save you time and > money and make your whole life easier. Backporting the upstream kernel > drivers to the handful of older kernels that are shipped by the distros > is much simpler than trying to maintain your tangled-web of macros and > wrapper functions that have been built up to support every kernel ever > created.
OK, now I see what you're getting at. We've discussed maintaining a few distro kernels "downstream" before; I think our concern was that while this approach works well for a small number of distros, it doesn't scale. Now, you could make the argument that it needn't scale; out-of-tree updates should be the exception, not the rule. I tend to agree, though we'll need to discuss this some more and decide which guests merit this sort of treatment and which don't. Since we're on the subject of overriding the distro's kernel modules with our own, what mechanism would you recommend for getting this done? I see several options: 1) Add some more logic to the Tools installer. We're part of the way there (we can build modules from source and deploy prebuilt modules), so we could add some overriding logic based on /lib/modules/updates or something. 2) Use dkms. We'd probably need to ship dkms with the Tools so that this will work on guests that don't come with dkms pre-installed. But I believe dkms is capable of both deploying prebuilt modules as well as cleanly overriding distro modules with its own. 3) Rely on distro driver update programs. Red Hat's driver update program mentions that we can ship a modprobe.d file that will override a Red Hat module in favor of own distributed by a hardware vendor (see "Overriding a Red Hat supplied driver" at http://driverupdateprogram.com). Of course, this method would only work for those distros that support a driver update program, which I believe is RHEL5, SLES9, and SLES10 (and I don't know whether Novell's partner driver process supports this sort of operation). > I'm guessing that you can remove over 2/3 of your code base if this were > to happen. > > Note that you are pretty much the only company trying to do this kind of > thing. Have you ever thought that perhaps this might not be the correct > model? Or did you just think that you all were somehow smarter than > everyone else? :) I plead the fifth. :) But seriously, I don't know for sure why we go to such lengths to get modules installed in people's kernels. I know that we've done it this way for a long time, and so I'm sure there's enough momentum behind it that it's difficult to change. If you could point me to some references online that describe how other companies approach this problem, I'd greatly appreciate it. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ open-vm-tools-devel mailing list open-vm-tools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
