Stefan Rompf <[EMAIL PROTECTED]> writes:
>> I even responded to it. Show me where he requests anything similar to
>> operstate_useroverride or IFF_WAIT?
>
> operstate_useroverride or IFF_WAIT are possible solutions to
[Jouni's mail]
For now they are just broken and that haven't changed since the first
versions. Still, Jouni haven't requested anything that complicated,
at least not in that email.
No wonder, both WAN and WLAN are very similar in this matter and
thus they need similar (or simply same) interface.
> -avoid the race I've just described to Jamal some minutes ago. This is
> important to me.
I've written this few times but you seem to keep ignoring it. You can't
do this all at a time:
- avoid the "race" (it's not a real race BTW)[1]
- keep it lock-free, remember about (S)MP and IRQs.
- have multiple unsynchronized access, including writing.
You don't want "races", you want multiple writers, you create a "critical
section" (or a "monitor" etc.) and you do _all_logic_ (not only variable
assignments) there. It's not important if the writers are in-kernel
or userspace, the number of independent (not synchronized) writers is
the key. This all assumes that an actual write and read operations _are_
atomic because if they aren't, even a simple read must be locked (and
that would be crazy as atomic operations are available).
You say I can continue with hdlc_set_carrier hack - yes, *I* certainly
can. But WLAN can't probably do anything like that. So a strange thing
is I seem to care more about _WLAN_ than about _my_ drivers (in fact,
I care most about _correctness_).
It's working fine now as there is only one variable - carrier state
- and only _one_ module has write access to it (hardware driver, or in
case of my drivers + hdlc_set_carrier hack - only one protocol driver).
We can go that path or we can choose multiple writers + locking. Either
way, it must be done _correctly_.
HT finally H.
--
Krzysztof Halasa
[1] "Race hazard, From Wikipedia, the free encyclopedia."
Not the best source probably but the first google showed.
"A race hazard (or race condition) is a flaw in a system or process where
the output exhibits unexpected critical dependence on the relative timing
of events."
-> no critical dependence, no race condition?
"Even after ensuring that single bit transitions occur between states, the
asynchronous machine will fail if multiple inputs change at the same time.
Solution: Design a machine so that each state is sensitive to only one
input change."
That's for electronics but it's essentially the same with computer
programs:
"A typical example of a race hazard may occur in a system of logic gates,
where inputs vary. If a particular output depends on the state of the
inputs, it may only be defined for steady-state signals. As the inputs
change state, a finite delay will occur before the output changes, due to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the physical nature of the electronic system. For a brief period, the
^^^^^^^^^^^^^^^^^^^^^^^
output may change to an unwanted state before settling back to the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
designed state. Certain systems can tolerate such glitches, but if for
^^^^^^^^^^^^^^^ ^^^^^^^^
example this output signal functions as a clock for further systems that
contain memory, the system can rapidly depart from its designed behaviour
(In effect, the temporary glitch becomes permanent)."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So that's at most a "glitch" and it becomes race when it's no longer
temporary (already posted an example BTW). Remember the "glitches" are
there with all patches we've seen (including my own which I definitely
have posted).
"Mutexes are used to address this problem in concurrent programming."
-
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
