svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net

[Rodney W. Grimes]

> On Mon, Feb 11, 2019 at 8:13 PM Patrick Kelsey <pkelsey at freebsd.org> wrote:
> 
> >
> >
> > On Mon, Feb 11, 2019 at 8:08 PM John Baldwin <jhb at 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.
> >
> >
> John,
> 
> Which is to say, I second your motion to proceed with normal process.  As

Point of order here, per the commiters guide you do not have the option
of seconding any motion that should of never been made, per rule 6 a
request by a Maintainer to revert your change has been made.  There
is no arguing on that point.

> one would reasonably expect, this driver didn't fall out of the sky
> yesterday.  It was completed on 15 November 2018 and has been undergoing

The code was committed to ^head 3 weeks ago, I dont care if it was
written 10 years ago, for this type of change and giving the current
issues that users of iflib based drivers are facing in stable/12 and
releng/12.0 I want this code out of stable/12 until we address and
verify that we have solved these other issues.

> multi-party testing since then.  I doubt it's bug free (nor was the last
> one), but when bugs have turned up in the driver or in iflib at any point
> along the way, convergence to root cause and a fix has been same-day, so I
> don't think there's anything that walks like an emergency or quacks like an
> emergency related to this commit.

None of this is an emergency, it is a simple mater of vmxnet3 is working
just fine, has been working just fine for a very long time, and is of know
quality.  What however is defanitly NOT an emergency is getting some new
iflib'ed version of this driver in the stable branch when we already have
issues in that branch with all the other iflibed drivers.

I am now upgrading my strongly suggest you revert to a flat out
revert this commit, with hat RE on.
-- 
Rod Grimes                                                 rgrimes at freebsd.org