Date: Sat, 11 Jan 2020 06:50:32 -0600 From: Josh Paetzel <jpaetzel@FreeBSD.org> To: Hiroki Sato <hrs@freebsd.org> Cc: "jpaetzel@freebsd.org" <jpaetzel@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: open-vm-tools in base Message-ID: <5822F9CC-4739-475D-A88A-A504E492A12E@FreeBSD.org> In-Reply-To: <20200111.122802.721369381057911241.hrs@allbsd.org> References: <20200111.122802.721369381057911241.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20 > On Jan 10, 2020, at 9:31 PM, Hiroki Sato <hrs@freebsd.org> wrote: >=20 > =EF=BB=BF"Josh Paetzel" <jpaetzel@FreeBSD.org> wrote > in <46480be7-b1a1-4da8-97ea-c4b97b0b997c@www.fastmail.com>: >=20 > jp> I've socialized putting emulators/open-vm-tools-nox11 in base to a > jp> small group of developers and gotten positive feedback, so I'm > jp> widening the audience. > jp> > jp> Proposal: Put emulators/open-vm-tools-nox11 in the base system of > jp> FreeBSD > jp> > jp> This port contains kernel modules and a binary to ease running FreeBSD= > jp> as a VM in a VMware virtualized environment. VMware supports this > jp> port by directly maintaining the code for it, however they do not > jp> include the FreeBSD version of the tools in the hypervisors > jp> anymore. (You can't just click "install guest tools" from the VMware > jp> management interface) > jp> > jp> Because these kernel modules are out of tree they are broken with some= > jp> regularity by changes to HEAD. By putting a version of them in tree > jp> changes to HEAD that broke the drivers and kernel modules would be > jp> more obvious to developers. > jp> > jp> I have never heard of a drawback or reason why you wouldn't want to > jp> run these tools. The main reason I see them not installed is due to > jp> people not knowing about them or forgetting to install them, or > jp> running VMs in environments where installing 3rd party software that > jp> needs an internet link is problematic. > jp> > jp> I'd continue to proxy changes back upstream as I've been doing for > jp> some time now. > jp> > jp> There is some precedent for this. Driver(s?) that were once a part of= > jp> the tools have been moved to base already. The VMXNET3 driver is an > jp> example of this. Also, the RC scripts that load the tools and start > jp> the userland daemons run a VMware included binary to check if the > jp> platform is supported by the tools, and just don't start them if it's > jp> an unsupported platform, so there's no danger to just trying to start > jp> them blindly across the default installs. >=20 > if_vmx was one ported from OpenBSD, not from open-vm-tools. VMXNET3 > driver of open-vm-tools was maintained separately and removed > recently. >=20 Ok, thanks for clarifying that. I=E2=80=99d modify my statement to be =E2=80= =9Cfunctionality the tools provided has been moved to base, ala VMXNET3=E2=80= =9D In the bad old days you had to create the VM with an e1000 NIC, install the t= ools. Change rc.conf, shutdown the VM. Change the VM hardware and power it b= ack on. These days you can select VMXNET3 and it just works.=20 > jp> Since emulators/open-vm-tools (the master port to > jp> emulators/open-vm-tools-nox11) depends on X11 and is not a candidate > jp> to include in the base system, I'd like to keep the ability to install= > jp> the package/port for both open-vm-tools and open-vm-tools-nox11 and > jp> let the user select which one is started. >=20 > I personally love to see open-vm-tools in the base system because it > improves user's out-of-the-box experience. As long as it is possible > to install emulators/open-vm-tools to override the stock version, I > see no harmful effect for both users who do not use VMware and ones > who want to use the latest version of open-vm-tools for some reason. >=20 > However, one thing I want to point out is that open-vm-tools is not > under BSDL. LGPL for the userland utilities and libraries, and GPL > for the kernel modules. More specifically, the vmmemctl driver for > FreeBSD is GPL'd, and vmblock is under 2-clause BSDL. Do we accept > GPL'd kernel modules? >=20 > Interestingly, modules for Solaris are under CDDL. When FreeBSD > Foundation visited VMware a while ago, they said GPL (or LGPL) was > chosen for compatibility with Linux kernel and they might be able to > release pre-GPL version of the source code under BSDL because they > wanted vendors/developer communities to maintain open-vm-tools > together. I am not sure if this is still relevant because it was > several years ago, but if we seriously think importing the kernel > drivers and maintaining them actively, asking it again might be worth > doing. >=20 > -- Hiroki I am aware of the licensing issue. VMware is motivated to get the tools into= the base system. They=E2=80=99ll dual license the current code to help faci= litate that. (They want something in return, a CI environment set up so they= can test FreeBSD on commit. Currently I build packages for them manually wh= en they request) I was not aware the Foundation had visited with VMware. It might be worth me= syncing up directly with the Foundation on this. Can you get a meeting sche= duled with the appropriate people on the Foundation side? Thanks, Josh Paetzel FreeBSD - The Power to Serve=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5822F9CC-4739-475D-A88A-A504E492A12E>