open-vm-tools in base

[Hiroki Sato]

"Josh Paetzel" <jpaetzel at FreeBSD.org> wrote
  in <46480be7-b1a1-4da8-97ea-c4b97b0b997c at www.fastmail.com>:

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.

 if_vmx was one ported from OpenBSD, not from open-vm-tools.  VMXNET3
 driver of open-vm-tools was maintained separately and removed
 recently.

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.

 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.

 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?

 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.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20200111/6723e087/attachment.sig>