Re: [PATCH] net br_netlink.c:y allow non "disabled" state for !netif_oper_up() links

[Andrew Lunn <andrew@lunn.ch>]

> > I also
> > wonder what the hardware drivers do? Since this is a change in
> > behaviour, they might not actually do anything.
> 
> For instance Marvell switches just set the state (see
> linux/drivers/net/dsa/mv88e6xxx/port.c) without checking for carrier status:

Yes, that was one i checked myself. I think i remember reviewing a DSA
driver which did not have a mechanism to disable a port, other than
the STP state. So there is a danger the mac_down() call is going to
change the STP state, and the mac_up() call will change it again.

> Yes, of course we can do it but (in case of MRP) the state machine must be
> altered in several points and, again, why the kernel should force such
> behaviour (i.e. introducing a policy) when drivers just don't consider it
> (see the above example).
> 
> The kernel should implement mechanisms while all policies should be into user space.

While i agree the policy should not be in the kernel, you have history
against you. Since this was never a requirement, and on first
mentioning it, it seems like an odd requirement, there is no guarantee
it will actually work for all drivers. So either you have to:

1) Say some kernel drivers are probably broken, will do horrible
   things to your network instead of being redundant, test it well
   before deploying.

2) Monitor for the link up event, and set the STP state as required.

The in kernel bridge/STP code takes this second approach, which again
reinforces the fact that because drivers never needed to support this,
some probably don't.

     Andrew