Hi Jamal, > 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.
we could protect operstate with a spinlock_irqsave() and then change it either from netif_[carrier|dormant]_on/off() or userspace-supplicant. However, I'm not feeling good about it. Look at rtnetlink_fill_ifinfo(), it is able to query a consistent snapshot of all interface settings as long as locking with dev_base_lock and rtnl is obeyed. __LINK_STATE flags are already an exemption, and I don't want operstate to be another. That's why I chose setting it from linkwatch in process context, and I really think this is the correct approach. > 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. Yes, first user would be Krzysztof, second wireless. > summary: avoid any device specific methods Please propose your alternative here. No offense, but this thread is getting way too long and too annoying that I'm willing to play the 'try another approach and I'll tell you whether I like it more'-game at this point. The main problem is that we have to store device properties concerning operstate transition somehow. I must say that I prefer a new (voluntary!) device specific method over some ugly IFF_I_AM_LOWERLAYERDOWN_INSTEAD_OF_DOWN flags or three new __LINK_STATE bits. > 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 have changed to the DORMANT flag as a compromise towards Krzysztof. He made clear that his drivers have several independant layers, one responsible for carrier, mapped to netdev_carrier*(), another one responsible for the protocol, mapped to netdev_dormant*(). I must admit that I'm not so happy with layers interoperating that bad, but on the other hand, I'm not a device driver developer beside occasionally hacking ipw2200 and willing to accept others' jugdement at that point. So discuss with Krzysztof ;-) > > 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. You've proposed netlink events for all transitions from and to the UP state. But an eventual userspace supplicant is more interested in transitions from and to the DORMANT state. As NOTPRESENT and TESTING are just unused enums for completeness, this sums up to all events are interesting, and for simplicity the supplicant should use the same notification mechanism. > 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 ;-> It's a real interesting question as there are some switches that support multiple 802.1X authentications per port, mainly that one can connect a dumb mini switch behind a protected port. So to answer your question, just use virtual devices with their own MAC address ;-) However, 802.1X frames are addressed towards the spanning tree multicast address and I really ask myself how the details work. Got to fetch some packet traces next time I have access to such a beast ;-) 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
