> > Since we're on the subject, I also want to say a few words about > > upstreaming VMware's kernel modules. In general we're getting more and > > more comfortable about upstreaming as some of us have been socializing > > the idea within the company. I think the remaining obstacle is this > > idea that once our code is upstream, we are no longer acting as the > > distributor, which means we can no longer control its destiny. We've > > shipped out-of-tree modules for years now and have grown accustomed to > > the control that this gives us; among other things, we can do things > > like release updated modules simultaneously with our products, or make > > whatever changes we want regardless of how locked down the affected > > distros might be (for example, we can add a new feature to a module > > intended for a distro that's been declared end-of-life by its vendor). > > It's very difficult to cede this control once you've enjoyed it for > > many product releases, which is partly why progress has been slow. To > > mitigate this problem, we're trying to understand whether, after > > upstreaming, we can gain some control back by working more closely > > with distros so that new features or changes that are important to us > > can be backported into existing distro releases in time for, say, a > > VMware product release. I don't have any details to share yet, but I'm > > sure either Ragavan or myself will say more about this in the near > > future. > > I don't see why you can't continue to still ship your drivers > out-of-tree just fine, as you do today, if the code is also in the > kernel tree as well. > > Why do you think this is somehow "giving up control"? How does this > prevent you from still providing specific modules for specific distros, > pre-build and ready to go? > > Overall, it will end up saving you engineering time and effort if your > code gets into the tree, as 75% of your driver lines of code will go > away (no need for the multiple layers of indirection to handle zillions > of kernel versions.) > > If you look around, this works just fine for almost all hardware > vendors, so it's not like this is a new model of doing work or anything > :)
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. Distros will periodically snapshot the upstream kernel and ship some version of our drivers. Additionally, we will periodically snapshot our downstream source and ship a large number of prebuilt drivers and the source itself as part of the VMware Tools, as we do today. Any given VM may or may not have some version of the drivers provided by the distro itself. When installing VMware Tools, our installer will need to choose whether to install the drivers we provide, or to depend on the drivers already found on the system. Some of this logic already exists in our installer today and we can extend it to check the versions of the drivers to make decisions like these, or we can ship dkms in our installer and use it to do this work. Also, it's not enough that these decisions be made when installing or upgrading VMware Tools; they also need to be made when the distro's kernel is upgraded. Again, this is something that dkms can do at boot-time. With this system in place, VMware is in a position to provide driver updates as it sees fit via the VMware Tools, and to deliver drivers via upstream for the best possible out-of-the-box experience. However, we've paid some high prices to get here: 1) All of our prebuilt driver infrastructure must live on and we must continue to add the latest distros as they are released. 2) We must maintain a separate "downstream" codebase which will continually subject us to API chasing headaches. 3) The "downstream" codebase is essentially a fork of the upstream codebase, so merging changes between the two is painful. 4) There are quite a few moving parts on the user's system tasked with making sure the user has the latest drivers, either from VMware or from the distro. The more complicated the system, the more fragile it will be. 5) The "downstream" codebase is released on VMware's product release schedule. Since it is distro-independent, each of its releases will need to be tested against each distro release. This is a sizable m by n testing matrix. So, what am I missing? ------------------------------------------------------------------------- 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
