svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net
freebsd at omnilan.de
Tue Feb 12 08:45:04 UTC 2019
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
>>>>> 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
>>> 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
>>> 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
Just a/my opinion from the users view!
More information about the svn-src-all