Thomas Graf <[EMAIL PROTECTED]> writes: > Well, firstly we cannot provide a perfect notification schema.
Of course, that's exactly was I said several times :-) > What I actually want to say is that we probably cannot guarentee > an up-to-date informal of all parties, what we can do is avoid > is inconsistency. So considering the above case, netif_carrier_on() > has to be syncronized by the caller, this means the carrier state > may not change while we're inside the function. Yes. But netif_dormant_off() isn't synchronized and it can cause the "inconsistency". That's precisely the same effect with my patch which you try fighting with yours. Note that this isn't a real inconsistency, e.g., we never signal IFF_RUNNING if no carrier was detected at the time frame, or if the device was simply down etc. It's just rather like Heisenberg's uncertainty principle, you can't really know the flag state if it's changing in this millisecond. > Secondly we know > that when the function is called, there must have been no carrier > for some time _if_ the carrier is currently set to off. This > means that the above code is only issued for legal carrier > resumes. Right. But a layer driving "dormant" flag may have not yet noticed and might now be doing dormant_off(). > The fact that we go to dormant state before changing the > carrier state makes dev_oper_state() behave correctly because in > case we actually call dev_oper_state() between netif_dormant_on() > and setting the carrier bit the interface will still be seen as > down and then switches to dormant in a single atomic operation. That's correct. But it may switch to "up" just thereafter, due to notification latencies. >> Protocol driver must still call netif_dormant_on() itself or IFF_RUNNING >> may be stuck for long. > > The IFF_WAIT flag can only be set by root, it is in his reponsibly > to handle this correctly. It is intended for userspace although > it can of course be used by drivers or stackable interfaces as well. I assume all flag changes from userspace require root. > Theoretically yes, it has the same "issues" as all other link states. Precisely. This is the same theory as with my patch. Thus, because we can't have such "strict" signaling without locks, and because we don't really need it (I can't imagine any routing solution which could need it or even notify the difference), I suggest giving it up and do all flag changes on their respective layers. -- 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
