From owner-freebsd-hackers@freebsd.org Fri Jan 10 20:22:07 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 004381F2BFC for ; Fri, 10 Jan 2020 20:22:07 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47vZCL5v8qz45v4; Fri, 10 Jan 2020 20:22:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 00AKLx5g001995; Fri, 10 Jan 2020 12:21:59 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 00AKLxjW001994; Fri, 10 Jan 2020 12:21:59 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net> Subject: Re: open-vm-tools in base In-Reply-To: <7de57db8-4f65-4350-9357-5138974ed405@www.fastmail.com> To: Josh Paetzel Date: Fri, 10 Jan 2020 12:21:59 -0800 (PST) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 47vZCL5v8qz45v4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 20:22:07 -0000 > > > 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