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. 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. > 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. It seems the same case as with WLAN. -- Krzysztof Halasa - 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
