On Thu, 2005-10-11 at 00:38 +0100, Krzysztof Halasa wrote: > Stefan Rompf <[EMAIL PROTECTED]> writes: > > > 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. > > That would be nice but isn't the case. With my WAN driver for sure, > but I think there are other cases as well.
I think if we use the concept of the driver being the proxy then all requests for state transition go through the driver, no? > And of course there is administrative status. I'm still not sure if > you want it there, though. > > > Is there really a need > > to have independant bits, especially considering the fact that it is really > > hard to be atomic if multiple bits need to be changed? > > It doesn't seem to be the case, either. If one bit represents one logical > state, you don't need to change more than one. Unless the design is > broken, of course. > > > As usage for the > > OPER_DORMANTL3* states is not so unrealistic, we might have much more than > > two bits soon. > > How more? I can only think of two: "dormant" (i.e., protocol down) > and "not connected" (i.e., inactive dial-up device, IFF_RUNNING = 1). > > > For ethernet, OPER_DOWN would be equivalent to no carrier. > > Well, I'm not exactly sure about that. Probably it should be renamed, > then? OPEN_DOWN suggests that the device is simply down, like after > ifconfig down. > no, thats admin status - defined using IFF_UP flag > > I'm not happy sharing write access to a dormant flag between a process and > > a > > kernel driver. > > Why not? The protocol driver would have to know about that, of course. > Of course, if we use "dormant" flag we already have protocol driver for > it. > > > 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 see an apparent problem here. The protocol driver would have to > be in charge, that's obvious. The userspace would be able to change flags > as permitted by the protocol driver. nod - and shall i mention you and i my friend finaly agree on something? ;-> I do think this approach will resolve any "race" issue - although i am not sure now if we can do this via netlink or it would be an ethtool extension etc. cheers, jamal > It seems the same case as with WLAN. - 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
