Hi Dominique, > Most of you probably know that I'm packaging open-vm-tools for openSUSE. The > packages seem to get quiet some echo and are appreciated.
We are definitely among the people that appreciate the work you have done (and continue to do) in packaging up open-vm-tools for openSUSE. Thank you. > That much that plenty of requests appear to have something similiar on the > 'host' (open-vm-tools are for the guest only). > > For openSUSE, we provide so called KMPs (Kernel Module Packages) for > additional drivers, which are always in sync with the latest updated kernel > version we publish. > Users basically look for a way to have their vmware installed on a system and > no need of taking care of the kernel modules when they update the > kernel (6.5 has sort of a mechanism that would ask for the root password and > recompile the kernel... but I have rarely seen it working.. normally it > segfaults somewhere). > > What stops us from including the vmware modules into the kernel? Good question. This question has come up on and off often enough that Adar thinks we need an FAQ. Perhaps. But for now, let me at least try and answer this here. As you have mentioned, there are both guest and host kernel modules. Our goal is to eventually get them all upstream. The guest modules will probably happen before the host modules simply because we have an active team working on the former. Now, coming to the reasons that have caused a delay in getting the guest kernel modules upstream. They are mostly (perhaps all?) internal to VMware. Here are a few (which have come up in various email discussions or FAQ posts in the past): 1. Each VMware product today ships with its own version of VMware Tools (and hence the guest kernel modules). While the differences may not be huge between each of these flavors, they are different nevertheless. As a result, there isn't one version of the kernel modules we can clean up and submit upstream. This is a pretty big priority for us and is a pre-requisite for moving towards upstreaming. 2. Slightly related to the above is the current development process for these kernel modules. VMware developers who work on these kernel modules do so in the context of VMware products, release timelines, deadlines etc. To move from this model to doing development upstream is a non-trivial change. Not a technical problem as much as a social one inside the company. 3. Also related to #2 is our current model of supporting new features in VMware products that also include changes to one or more of the guest kernel modules. Since we currently distribute both the product and the guest kernel modules at the same time, we have a lot more control and flexibility in enabling features for our customers. While others (including Greg KH) have pointed out that most other IHVs do *not* do this, the fact is this is our current mode of operation. And whether or not we should change this is still a matter of internal debate. There are a few more, but I think I have already gone into a lot more detail than most people are probably interested in. Having said all this, I should also add that we are currently working on #1 above as it really is the first step we need to take internally. We are also socializing #2 inside the company, so I am cautiously optimistic that we will make progress on this upstreaming topic in the coming weeks/months. > I am even able to pass along an offer from a kernel dev (Greg KH) to format > the > drivers for inclusion and offering his help in getting the modules in. I > think Greg is known to most of the Kernel hackers and does not need any > further introductions. Otherwise, for sure you know the Linux Driver Project. Adar and I met with Greg at a conference last year where he extended this offer. He has repeated this on several occasions since then. I fully hope to be able to take him up on his offer as well as maybe even use the services of the Linux Driver project. But, as I've explained above we have a few internal steps to take care of first before we can take this one on. > Everything we can do to make the life of users easier on any platform should > be a good thing to do. Agreed. open-vm-tools was/is a step in that direction. Upstreaming is another and we expect to get there. Regards, Ragavan ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ open-vm-tools-devel mailing list open-vm-tools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
