Am Donnerstag 10 November 2005 01:02 schrieb Thomas Graf: > Assuming we use the overwrite schema you propose, right. The actual > representation would no longer be atomic though, e.g. when the bonding > master access the oper state from its slave you will suffer the exactly > same issues as with the flags when the overwrite value is changed.
My thoughts on this are these: If we have one consolidated state, it is stable when linkwatch_fire_event() is called. There we could save the state and forward it to the workqueue, that forward it to the registered handlers. Bonding would not need to poll then, but use this notification. Even though we don't do that now, we could thanks to the cleaner semantics. With bit fields and linkwatch_fire_event() called after every bit change, this simply won't work. > The problem really is that we limit ourselves to those states and for > every combination of "attributes" a new state has to be introduced > which at some point will make >= comparisons like you propose > imopssible. May be this is a new way to see our discussion. It seems that our main difference is not bit fields vs. one state, but how much operational state we want to have generic. Let's face it, every protocol has an operational state that goes beyond RFC2863 or netif_(carrier|dormant). This can be negotiated speed and duplex for ethernet, or whether multilink is enabled on a PPP connection. The netif_(carrier|dormant) approach tries to define only the states as generic that are needed now for kernel queueing/L3 to operate. It rather keeps more state at the protocol level, can be more precise there, it doesn't care so much about atomic changes. Different to that, my RFC2863 derivation tries to represent a larger part of the state as generic. This requires protocol/hardware drivers to do some mapping, e.g. no ethernet link =~ OPER_DOWN. However, it allows higher levels, both in kernel and userspace, to have one flag that says more about the operational state. The main reason why I chose RFC2863 definitions is because it is a standard and therefore known. May be if we continue discussion from this viewpoint, we can advance. > Do you see any problems with just deriving the operational state from > the flags like illustrated in my patch? I'm trying to take over here, > I'm just trying to get the best out of it considering all aspects. Honestly, if we don't do RFC2863 like states in the kernel, I would also present the IFF_RUNNING and IFF_ESTABLISHED / IFF_DORMANT towards userspace. > > As usage for the > > OPER_DORMANTL3* states is not so unrealistic, we might have much more > > than two bits soon. For ethernet, OPER_DOWN would be equivalent to no > > carrier. > > Right, this means we cannot check the carrier state while the interface > is administratively down. Even now, IFF_RUNNING is supressed if !IFF_UP. Quite a bunch of devices shuts hardware down when the device is closed anyway, so we can't reliably query carrier state then. Stefan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
