* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 00:09 > + OPER_UNKNOWN = 0, > + OPER_NOTPRESENT, /* unused, placeholder */ > + OPER_DOWN = 16, > + OPER_LOWERLAYERDOWN, > + OPER_TESTING = 32, > + OPER_DORMANTL3DOWN = 48, /* OS queue start from here */ > + OPER_DORMANTL3UP = 64, /* L3 should try using interface */ > + OPER_UP = 96
Where are we going to present the hardware-not-present state in your interpreation of the rfc? Couldn't we use OPER_NOTPRESENT for this? The description in the rfc is very generic. > I favour a defined link between enabling the scheduler (dev_activate() and > stuff), L3 considering the interface and operstate. I say let's > dev_activate() on OPER_DORMANTL3DOWN so that wpa_supplicant can send packets. > Activate L3 when OPER_DORMANTL3UP is reached. > > A dial on demand interface that is able dial would be OPER_DORMANTL3UP to > allow L3 traffic to it. However, if it goes OPER_DOWN for some reason, L3 > wouldn't consider it. We lose this if we remove OPER_DORMANTL3UP and specify > permant routes instead. I see, marking routes to be permanent is no option to me anyways. Static routes are permanent by definition in my interperation. > I think it is valid to define the operational state as one field simply due > to > the fact that the driver is solely responsible for it. 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. This is minor however and no problem. 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. I just don't feel good about switching to a state based schema, the actual effect on all the async notifications is very hard to predict. I absolutely like the schema you propose thoug, I wasn't sure about the L3 special part but I'm beginning to see its (limited) value, it's better as just disabling routes on !IFF_RUNNING as others propoes. Nevertheless, I'm sticking to my viewpint, I think this should be handled by userspace itself. ;-) 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. > 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. > I'm not happy sharing write access to a dormant flag between a process and a > kernel driver. What if we need to add a userspace supplicant up onto one of > those WAN devices that want to write to the dormant flag because we need (yet > fictional) 802.1X over HDLC? I don't want to touch that stuff again then, > likely breaking userspace API to existing supplicants. I'm not sure I see the difference in your approach except for the additional dormant state. Maybe we should postpone this until we agree on the actual kernel internal state of things. - 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
