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

[Harry Schmalzbauer]

Am 12.02.2019 um 02:25 schrieb Rodney W. Grimes:
>> 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.
> 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