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

[Jiri Pirko <jiri@resnulli.us>]

Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
>On Thu, 13 Dec 2012 16:17:33 -0200
>Flavio Leitner <fbl@redhat.com> wrote:
>
>> On Thu, 13 Dec 2012 10:09:33 -0800
>> Stephen Hemminger <shemminger@vyatta.com> wrote:
>> 
>> > On Thu, 13 Dec 2012 15:54:23 -0200
>> > Flavio Leitner <fbl@redhat.com> wrote:
>> > 
>> > > 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).