Messages in this thread | | | Date | Fri, 18 Sep 1998 14:54:18 -0700 | From | "David S. Miller" <> | Subject | Re: tulip driver in 2.1.11* - 2.1.21 is broken - new driver |
| |
Date: Fri, 18 Sep 1998 11:20:23 -0700 (PDT) From: Linus Torvalds <torvalds@transmeta.com>
On Fri, 18 Sep 1998 kuznet@ms2.inr.ac.ru wrote: > "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.
Btw, can we get rid of all the "dev->tbusy" and "dev->interrupt" flags, and just use a regular spinlock or something around each driver?
dev->tbusy says "My TX queue is full, please stop asking me to send new packets until this flag clears, thanks".
dev->tbusy has always been a bug, with no redeeming features. It's really only a way to say "yes, I have a bug, and I want to know about it" instead of fixing the problem properly.
Incorrect for dev->tbusy, it has a specific purpose and does that job well. The problem is that Becker's drivers in particular decided to give it this "new use" for start_xmit/bh atomicity which is completely bogus.
dev->interrupt I believe falls into a similar category, no code outside of drivers even reference it and for all cases I see it used it is "hey we reentered the interrupt handler, report a debugging message and return" which is complete garbage.
So I think dev->interrupt should disappear, and dev->tbusy should stay as is.
Later, David S. Miller davem@dm.cobaltmicro.com
- 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/
| |