[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1392577012.15615.116.camel@deadeye.wl.decadent.org.uk>
Date: Sun, 16 Feb 2014 18:56:52 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: "Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc: netdev@...r.kernel.org, xen-devel@...ts.xenproject.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
"Luis R. Rodriguez" <mcgrof@...e.com>,
Stephen Hemminger <stephen@...workplumber.org>,
bridge@...ts.linux-foundation.org
Subject: Re: [RFC v2 1/4] bridge: enable interfaces to opt out from becoming
the root bridge
On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@...e.com>
>
> It doesn't make sense for some interfaces to become a root bridge
I think you mean 'root port'.
> at any point in time. One example is virtual backend interfaces
> which rely on other entities on the bridge for actual physical
> connectivity. They only provide virtual access.
>
> Device drivers that know they should never become part of the
> root bridge have been using a trick of setting their MAC address
> to a high broadcast MAC address such as FE:FF:FF:FF:FF:FF. Instead
> of using these hacks lets the interfaces annotate its intent and
> generalizes a solution for multiple drivers, while letting the
> drivers use a random MAC address or one prefixed with a proper OUI.
> This sort of hack is used by both qemu and xen for their backend
> interfaces.
>
> Cc: Stephen Hemminger <stephen@...workplumber.org>
> Cc: bridge@...ts.linux-foundation.org
> Cc: netdev@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
> ---
> include/uapi/linux/if.h | 1 +
> net/bridge/br_if.c | 2 ++
> net/bridge/br_private.h | 1 +
> net/bridge/br_stp_if.c | 2 ++
> 4 files changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
> index d758163..8d10382 100644
> --- a/include/uapi/linux/if.h
> +++ b/include/uapi/linux/if.h
> @@ -84,6 +84,7 @@
> #define IFF_LIVE_ADDR_CHANGE 0x100000 /* device supports hardware address
> * change when it's running */
> #define IFF_MACVLAN 0x200000 /* Macvlan device */
> +#define IFF_BRIDGE_NON_ROOT 0x400000 /* Don't consider for root bridge */
[...]
Does it really make sense to add a flag that says exactly which special
behaviour you want, or would it be better to define the flag as a
passive property, which other drivers/protocols then use as a condition
for special behaviour?
The fact that you also define the IFF_BRIDGE_SKIP_IP flag, and set it on
exactly the same devices, makes me think that they should actually be a
single flag. I don't know how that flag should be named or described,
though.
Ben.
--
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists