Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge

From: Zoltan Kiss
Date: Fri Feb 21 2014 - 08:03:16 EST


On 20/02/14 20:24, Luis R. Rodriguez wrote:
On Thu, Feb 20, 2014 at 9:19 AM, Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> wrote:
On Wed, 19 Feb 2014 09:59:33 -0800 "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> wrote:
On Wed, Feb 19, 2014 at 9:08 AM, Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote:

Please only use the netlink/sysfs flags fields that already exist
for new features.

Sure, but what if we know a driver in most cases wants the root block
and we'd want to make it the default, thereby only requiring userspace
for toggling it off.

Something in userspace has to put the device into the bridge.
Fix the port setup in that tool via the netlink or sysfs flags in
the bridge. It should not have to be handled in the bridge looking
at magic flags in the device.

Agreed that's the best strategy and I'll work on sending patches to
brctl to enable the root_block preference. This approach however also
I don't think brctl should deal with any Xen specific stuff. I assume there is a misunderstanding in this thread: when I (and possibly other Xen folks) talk about "userspace" or "toolstack" here, I mean Xen specific tools which use e.g. brctl to set up bridges. Not brctl itself.
requires a userspace upgrade. I'm trying to see if we can get an
old-nasty-cryptic-hack practice removed from the kernel and we'd try
to prevent future drivers from using it -- without requiring userspace
upgrade. In this case the bad practice is to using a high static MAC
address for mimicking a root block default preference. In order to
remove that *without* requiring a userspace upgrade the dev->priv_flag
approach is the only thing I can think of. If this would go in we'd
replace the high static MAC address with a random MAC address to
prevent IPv6 SLAAC / DAD conflicts. I'd document this flag and
indicate with preference for userspace to be the one tuning these
knobs.

Without this we'd have to keep the high static MAC address on upstream
drivers and let userspace do the random'ization if it confirms the
userspace knob to turn the root block flag is available. Is the
priv_flag approach worth the compromise to remove the root block hack
practice?

Luis


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/