Skip site navigation (1)Skip section navigation (2)
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>