Am Mittwoch 09 November 2005 22:25 schrieb Thomas Graf: > > However, L3 > > would lose the possibility to differenciate between a dialer that can > > dial and one that can't. I don't consider this limitation too bad, but it > > would be there and stay for a while. > > Could you elaborate on this, I'm not quite sure if I understand.
Let's look again at the kernel states I've suggested: + 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 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'm sorry to come up with this again but I haven't seen your solution > to the problem that your implementation cannot keep track of the carrier > state while in operational state is "down". Do we gain anything by using > the state model rather than just representing it by deriving it form the > flag based state? 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. 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? 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. > I don't think it's bad but userspace only has to be able to trigger > dormant->up and up->dormant, no? So couldn't we solve this in an easier > way with just a flag? 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. 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
