From owner-freebsd-hackers@freebsd.org Fri Jan 10 20:56:33 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 8A0541F39B9 for ; Fri, 10 Jan 2020 20:56:33 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47vZz51jt8z480n for ; Fri, 10 Jan 2020 20:56:33 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 26E9521B6B for ; Fri, 10 Jan 2020 15:56:32 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 10 Jan 2020 15:56:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=m4VCxh ZYldIo0FxOoApdSvJLmUTHVaegCcddnMlFufg=; b=HSTlNoIt6Qgm0rE/NeDONC UAWruCZSmg8zNsWo7oQastQBj82Fj4OC9HaxARKxLJAyajJ5fXpptDkQOM+vw3es fqARAWeH98KNgi8V37xy36c4LIP51iD3Tobk+x9AppRimSIAMhPm5QHsB2K25K0v c85PqOlr4/hgrMVD9t2AMSAwcVsDyVXNqj1+R+PkXWwbseXV9l9ipHgjHXvURAOd 4gvdyiW5woijLZSfOLyr5ReLNLSO8WnTVwuvvzjN+Xi2FPDSl8MsLHnaKRXPA3OF 3XVhPILONkKs8jx83bNxbIPlVBbjJMzMXuNr7BXVii4o4jdtRDgtOtQKToL4wr2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeifedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdflohhshhcurfgrvghtiigvlhdfuceojhhprggvthii vghlsefhrhgvvgeuufffrdhorhhgqeenucffohhmrghinhepfhhrvggvsghsugdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomhepjhhprggvthiivghlsefhrhgvvgeuufffrdho rhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EBCB8E00A2; Fri, 10 Jan 2020 15:56:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-740-g7d9d84e-fmstable-20200109v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net> References: <202001102021.00AKLxjW001994@gndrsh.dnsmgr.net> Date: Fri, 10 Jan 2020 14:56:11 -0600 From: "Josh Paetzel" To: freebsd-hackers@freebsd.org Subject: Re: open-vm-tools in base Content-Type: text/plain X-Rspamd-Queue-Id: 47vZz51jt8z480n X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US] 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:56:33 -0000 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