Hi Stefan, I looked at the patch and while there are some stylistic/implementation differences between us, I think generally all the concepts seem to be in place. So we are almost there.
More comments below: On Fri, 2005-18-11 at 21:52 +0100, Stefan Rompf wrote: > This is the data flow: > > -Device changes __LINK_STATE_(NOCARRIER|DORMANT) flag > -linkwatch is scheduled > -During linkwatch, the device is queried for it's operational state either > using a device specified method or a generic one I think this is where we differ more than anywhere else. A good goal is to avoid any new netdev methods. My earlier suggestion was to have the device totally oblivious of transitions to/from dormant in particular ones whose natural state transition is from up<->down such as ethernet. IOW, A netdevice continues to call netif_carrier_on/off and depending on link_mode it may be transitioned to up/dormant etc. So an ethernet driver doesnt know it needs to go from detecting peer link is up to next being authenticated in the case of 802.1x. It just calls netif_carrier_on which checks link_mode to decide on transition. After looking at your patch, however, i realize that using only that approach it will be insufficient; some devices doing kernel based things during dormant state may wish to do the transition to/from dormant. For those, I think we will need to make explicit changes to call netif_carrier_dormant_on etc. But those are a minority of the devices and they can be changed over time. summary: avoid any device specific methods > -Operational state is limited to IF_OPER_DORMANT if link mode tells so > > -state is written to dev->operstate > -notification is sent out via netdev_state_change() as before > > Userspace can intervene after setting link mode to IF_LINK_MODE_DORMANT > (implementation incomplete as I'm yet not familiar enough with writing values > through netlink, Thomas, can you help here?) > -Calls pseudo_set_operstate() > -operstate is either changed from DORMANT to UP or reverse > > -notification is sent out via netdev_state_change() > > linkwatch and pseudo* as serialized by rtnl and dev_base_lock. > > To demonstrate a stacked device, I've implemented a private RFC2863 state > query for VLANs that goes to LOWERLAYERDOWN if the underlying device is DOWN. > > With the device specific RFC2863 state query method, we could even limit > LINK_STATE_DORMANT to the devices that need it, but I have the impression > that this is generic enough to be part of struct net_device. > I am still unsure why DORMANT is part of dev->state. Shouldnt something be tracking exactly what state we are in as you had it in your earlier patch? I liked that approach. > I'm currently emitting more netlink notifications than you've shown in your > state diagram. I'll comment on this later, still got other stuff to do for > today. > ok, will wait for that. > > -> UP->DORMANT; i am not sure if that transition is needed. > > Anyway, this transition is needed. Switches can be configured to rerun 802.1X > regularly after initial authentication. Ok, i agree after your explanation above; i have some questions on multi-suplicant 802.1x in one node and one ethernet port and relationship to oper state but i wont distract the current discussion. So dont respond, just think about it ;-> cheers, jamla - 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
