Date: Fri, 10 Jan 2020 14:56:11 -0600 From: "Josh Paetzel" <jpaetzel@FreeBSD.org> To: freebsd-hackers@freebsd.org Subject: Re: open-vm-tools in base Message-ID: <c37ff1cc-94fc-4a75-aa97-938d6d24db0c@www.fastmail.com> In-Reply-To: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net> References: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 10, 2020, at 2:21 PM, Rodney W. Grimes wrote: > > > > > > 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 > There's no argument at all. I am simply looking for perspectives that I haven't considered. > Building this short list of ports a few times a day > should be trivial for the CI infustructure. > That already happens. I was notified within about 2 hours that a HEAD commit had broken the port. > As you stated the maintenance workload is invariant, > so all that is really neded is early identification. > Take for instance the latest breakage, r355732. From the commit message: " All in-tree consumers have been converted to callout(9)." Had open-vm-tools been in tree it wouldn't have gotten broken at all. But in the worst case I would be committing to src instead of ports. Either way I still have to upstream the changes. It's no more or less work either way. So the pros are really two parts, part one is making the code more visible to the src developers so they can chase changes. (It's very rare that people committing ABI breaking changes don't also modify all the consumers) and the second part is.... > And for pespective I run a lot of ESXi and FreeBSD guests... so > any bias I might have is in the wrong direction :-) > ...things would be a lot more convenient for people who run virtualized FreeBSD instances. This would Just Work (TM) and who doesn't love changes that move us closer to a "Just Works out of the box" state? > > > Steve > > Josh Paetzel > -- > Rod Grimes rgrimes@freebsd.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Thanks, Josh Paetzel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c37ff1cc-94fc-4a75-aa97-938d6d24db0c>