Date: Tue, 12 Feb 2019 09:44:59 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: rgrimes@freebsd.org, Patrick Kelsey <pkelsey@freebsd.org> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-12@freebsd.org Subject: Re: svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net Message-ID: <47b11231-32d5-df41-2043-25f26484c664@omnilan.de> In-Reply-To: <201902120125.x1C1PX7G073631@pdx.rh.CN85.dnsmgr.net> References: <201902120125.x1C1PX7G073631@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 12.02.2019 um 02:25 schrieb Rodney W. Grimes: >> On Mon, Feb 11, 2019 at 8:08 PM John Baldwin <jhb@freebsd.org> wrote: >> >>> On 2/11/19 4:26 PM, Rodney W. Grimes wrote: >>>>> Author: pkelsey >>>>> Date: Mon Feb 11 23:24:39 2019 >>>>> New Revision: 344027 >>>>> URL: https://svnweb.freebsd.org/changeset/base/344027 >>>>> >>>>> Log: >>>>> MFC r343291: >>>>> Convert vmx(4) to being an iflib driver. >>>> I strongly object to this MFC, given the current number >>>> of 12.0 RELEASE related iflib problems we have it is >>>> foolish of us to iflib any more drivers in 12.0 >>> This isn't the release branch though and presumably we have some time >>> before >>> 12.1 ships. If there are reports of vmx(4) breakage on stable before 12.1 >>> we could always revert this commit then? >>> >>> I've heard of some EN's for 12.0 for iflib fixes. Are those fixes in >>> stable/12 >>> yet or are we still waiting for them to land in HEAD and/or be merged? >>> >> iflib.c is currently the same between head and stable/12. I've found and >> fixed a number of iflib bugs by developing the iflib version of the vmx(4) >> driver, and it's also being fielded in a product. I'm also aware that not >> all current driver problems are necessarily iflib problems. I think we'd >> be better off letting this version of vmx(4) ride it out in stable/12 until >> such time as we discover an actual horror that we then feel we need to >> react to in some way other than just going ahead and fixing it. > It can ride it out in head just fine, give it 3 months... plenty of time > before any 12.1. stable/12 IS NOT A TEST GROUND. I don't think the intention of this MFC is to test the iflib(4) version of vmx(4), but to improve the driver, which has been tested locally by the devop and also in HEAD for some time. Many regressions/problem(combinations) aren't found during HEAD lifetime, but after MFC. And in case of iflib(4), it wasn't the MFC to -STABLE, but after -RELEASE. If it would have had a wider production (-STABLE) usage, possibly... As long as the devop isn't aware of known, yet to fix _additional_ bugs or any regression, I'm happy to reduce my local MFC patchset and have it in STABLE as soon as the devops MFC timeframe lapsed without a single regression/problem notification. I've never updated any -stable production machine relying on the hope someone else tested every possible change. That's what I'd like to beeing allowed to expect from -RELEASE; which hasn't ever been true for major version updates. So this MFC won't harm -stable in any form, but will improve 12.1-release quality. Just a/my opinion from the users view! Thanks, -harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47b11231-32d5-df41-2043-25f26484c664>