Re: [patch net-next 0/4] net: allow to change carrier from userspace

Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:

On Thu, 13 Dec 2012 16:17:33 -0200
Flavio Leitner [off-list ref] wrote:

quoted

On Thu, 13 Dec 2012 10:09:33 -0800
Stephen Hemminger [off-list ref] wrote:

quoted

On Thu, 13 Dec 2012 15:54:23 -0200
Flavio Leitner [off-list ref] wrote:

quoted

I am saying this because people are used to and there are scripts out
there using something like:
# ethtool <iface> | grep 'Link'
to react an interface failure.

Then the script is broken. It is asking about hardware state.

I was talking about the team master interface, so it makes sense
to check its 'hardware' state. Just think on 'bond0' interface
with no slaves. It should report Link detected: no.

See bond_release(), what happens if bond->slave_cnt == 0, for instance.

I was thinking more that ethtool operation for reporting link on
the team device should use the proper check rather than just using netif_carrier_ok(),
the team ethtool operation for get_link should be check IFF_RUNNING flag
in dev->flags which is controlled by operstate transistions.

I admit I'm bit confused now.

For example in bridge code:
in br_add_if() - netif_carrier_ok() is checked and by the value it is
decided if br_stp_enable_port() is called or not. Wouldn't it make more
sense to check IFF_RUNNING (or netif_oper_up()) here?

The reason I'm asing is that if team device is in bridge, carrier is
always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
userspace, in current code, bridge wouldn't know the difference...

There are more exmaples of similar usage of netif_carrier_ok() in
bridge (called on ports), bonding (called on slaves), team code (called on ports).