Date: Fri, 10 Jan 2020 12:21:59 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Josh Paetzel <jpaetzel@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: open-vm-tools in base Message-ID: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net> In-Reply-To: <7de57db8-4f65-4350-9357-5138974ed405@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On Fri, Jan 10, 2020, at 12:38 PM, Steve Kargl wrote: > > On Fri, Jan 10, 2020 at 10:44:38AM -0700, Warner Losh wrote: > > > On Fri, Jan 10, 2020 at 10:26 AM Steve Kargl < > > > sgk@troutmask.apl.washington.edu> wrote: > > > > > > > On Fri, Jan 10, 2020 at 09:55:23AM -0600, Josh Paetzel wrote: > > > > > > > > > > There is some precedent for this. Driver(s?) that were once a > > > > > part of the tools have been moved to base already. The VMXNET3 > > > > > driver is an example of this. > > > > > > > > > > > > > There is also precedent for removing a working driver from > > > > base and putting it into ports. See drm2. > > > > > > > > > > Not the best example to cite as there's been a lot of bumps with that and > > > the future distribution model is unclear to me. > > > > > > > Oddly enough I disagree. :-) > > > > Does the problems for open-vm-tools occur in freebsd-stable, > > where the kernel ABI should be stable? > > > > HEAD breakage is most common. There have been a few MFCs that have broken STABLE over the years but they are rare. > > > Freebsd-current is the development tree, and kernel changes > > might break 3rd party software. drm2 is a perfect example. > > In-base drm2 was working just fine and kept up-to-date with > > kernel changes when it was attached to the build. This seems > > to be what Josh wants for open-vm-tools. > > Can you clarify which part of my proposal wasn't clear? Or is "seem to want" just a conversational usage of language. > > > Once drm2 was detached > > from the build it was ocassionally broken, and someone (often > > times me) would find and report the breakage. If open-vm-tools > > is added to base, and then someone adds emulators/open-vm-tools-devel > > which supercedes in-base open-vm-tool, we're back to the in-base drm2 > > situation. > > > > I believe I addressed that in my initial email. If there is a /usr/local version of the tools installed the user can select between the base system version and the "3rd party" install. > > > Finally, open-vm-tools is used by what percentage of FreeBSD users? > > 1%? 5%? 50%? > > > > I don't believe we have the data to answer that. I can give some ancillary data though: > > When I was involved with FreeNAS ESXi was the single most popular platform to run it on, even though we straight out told people virtualizing FreeNAS wasn't recommended. (At one point 30% of the ~100K systems that were phoning home were reporting ESXi as their hardware platform) > > The last two places I've worked the virtualized FreeBSD instances outnumbered the on the iron FreeBSD systems by 10:1. (and one of those places was a hardware vendor that specialized in FreeBSD!) > > My personal belief is that it could be greater than 50%. That wouldn't surprise me. > > However, since there is precisely zero downside to including the open-vm-tools in a hardware install, my counter question to you would be "what difference does the percentage make?" > > I don't see an actual reason for an objection in your email. > > We're not talking about changing the maintenance workload here, just shifting it around. Perhaps rathan than have this argument over if this should be moved to ports find a road map that stops, or atleast very early identifies base system changes that cause breakage for these heavly base system dependent ports (short list here I am sure there are more:) drm2 lsof open-vm-tools virtualbox Building this short list of ports a few times a day should be trivial for the CI infustructure. As you stated the maintenance workload is invariant, so all that is really neded is early identification. And for pespective I run a lot of ESXi and FreeBSD guests... so any bias I might have is in the wrong direction :-) > > Steve > Josh Paetzel -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202001102021.00AKLxjW001994>