On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote:OK. as your wish.
On 04/23/2014 07:41 PM, Ben Hutchings wrote:What Ben is saying is that RHEL doesn't use 2.6.32.y, but did their own
On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote:Hi, Ben
On 04/23/2014 01:53 AM, Ben Hutchings wrote:[...]
RHEL 6 isn't based on 2.6.32.y, they do all their own backporting.For what it's worth, I would recommend against applying this. I don'tIf we do not merge these patches, maybe RHEL 6 can not make tap driver
think even Red Hat has backported the VLAN changes, and they have been
quite aggressive about backporting features to RHEL 6.
support vlan well.
It is well known that extraction vlan tag is not implemented in kernel
2.6.32.y. Kernel 2.6.32.y depends on nic hardware to extract vlan tag.
So if the patches are not applied, tap driver can not support vlan well.
fork of 2.6.32 so even if we merged your patch, they wouldn't pick it
from this tree anyway. However they could possibly take your patch if
some customers requested the feature even if it's not in 2.6.32.y.
Clearly, the fact that nobody complained about this in 4.5 years of
2.6.32 means that there's no particular reason any user would suddenly
miss it now. 2.6.32.y is mostly used to update existing deployments but
rarely for new deployments. That's why the usefulness of your backport
in this kernel for its users is likely limited, and at the same time
the risk of causing a regression is far from being null for existing
users (eg: if some worked around the issue a different way, their
workaround would likely not work anymore).
Best regards,
Willy