Stefan Rompf <[EMAIL PROTECTED]> writes: > Please reread what is written about locking in net/core/dev.c. It has > looked a > bit strange to me, too, when I needed to use it for the first time, but my > code does the right thing here. Remember, linkwatch_fire_event() is _NOT_ a > pure reader.
It doesn't look strange to me but ok, I'm not going to point you such things anymore, you know better. >> What does calling from process context change here? That would be true >> with BKL and, say, Linux 2.0 but it's no longer the case. rtnl lock >> protects you from userland, though. > > Wrong. But what is exactly wrong? > See, I've clearly stated in my patch that I expect the driver to synchronize > calls if netif_set_kernel_operstate(), as does currently expect > netif_carrier_on/off() (documented in netdevice.h). The question for you is > whether such an expectation is totally unacceptable. Looking at your driver, > I see no reason why. There is no such thing as "my driver". There are two independent layers of drivers (hardware drivers and protocols) and it seems logical that each one control its respective status. It was previously done with a hdlc_set_carrier hack (due to a lack of protocol-up flag) but it was pointed to me that I should get rid of it and in fact I agree with that opinion. Anyway I'll keep a look at your progress. Hope you'll have usable interface in the tree soon. -- 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
