Stefan, On Tue, 2005-22-11 at 21:38 +0100, Stefan Rompf wrote:
> 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. Ok, what you have is fine by me. > 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. Your call - I dont think we have differences of opinions at the conceptual level; > > 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 saw the discussion with Krzysztof - i think whatever agreement you come up with him is fine as well. So whats left? I note you asked Thomas for help on the other email for something netlink related - is that it? > 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. The reason is: the typical recommended events/traps are from down state. So this fits for dormant as well. But what about apps like routing daemons? IFF_RUNNING assumes the event has relationship with up/down. > 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. > As long as the apps like quagga etc can also relate should be fine. > > 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 ;-) Well, thats certainly one way. Then the oper state machines you are working on + stacking will work well. But this depends on if you can justify the reason for those virtual devices. With wireless you can probably justify to map the radio layer to a virtual device if you have a card that has multiple radios; i dont know how it would work if you join different access points (and each requiring authentication phase) with a standard 802.11 - someone told me a while back, this may be common for mobility so that handoff from one access point to another is easier. > 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 ;-) > What i have seen (on ethernet not wireless) is something that uses MAC address filtering; think of a bridge/L2 switch that doesnt learn src addresses but instead lets the 802.1x deal with it if src is not found in the table. The reason i asked you earlier, btw - is because what you are trying to do is tightly coupling 802.1x to port operational state and that there are exceptions to the rule; unless you turn everything into a netdevice which maybe unreasonable unless you can justify something needs to be a netdevice ;->. Anyways, this has nothing to do with the operational state discussion - thats why i said we can discuss later - even privately. cheers, jamal - 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
