> On the fast routing code, it is nice that he told you and even told me
> his gripes, but what really needs to happen is that he must work out
> these issues with ANK who created and can fixup any problems the fast
> routing code has.
Robert Olsson has already merged fastroute to 0.89H.
BTW what did Donald tell you?
> I do agree that the current implementation is a little messy.
> Consider it as an example technology, and something we need to fix up.
I see no mess here. If Donald will not break drivers' reenterancy
explicitly by introduction of some internal locks, fastroute
can be maintained separately.
"re-entering interrupt handler" is not a big problem too.
Donald made some wrong assumptions on linux irqs,
and it will result in unpleasant surprises from time to time.
It is very easy to fix, I'll make it when merging fastroute.
> that should have been fixed some time ago (ie the use of "tbusy" as a lock
> which needs to use atomic operations).
"tbusy" was never used as lock (at least in tulip.c)
Transmitter is locked by bh_atomic in normal mode,
and by tx_semaphore in fastroute mode.
dev->tbusy is just flag, exported to upper layers.
Test_and_set dev->tbusy at the very beginning of transmit
routine is just the most silly way to recover from hardware/driver bugs,
rather than a lock. Making it atomic is redundancy.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/