They are performance important. And afaik you btw made dev->interrupt a long
word to cover for the fact the atomic stuff doesnt work on char ;)
> or even better just a well-defined "dev->spinlock". Right now it's very
> obvious that nobody knows the proper meaning of either tbusy or interrupt.
tbusy is NOT a spinlock. I know that, Donald knows that, Dave knows that,
ANK knows that. tbusy is the flow control between the driver queues and the
driver. Without the tbusy tests the moment your machine fills a queue you
die.
Using tbusy as anything other than flow control -is- misusing it. Several
drivers do misuse it. The 3c501 is as good example.
tbusy is extremely simple
When you can accept no more frames a driver sets dev->tbusy=1. When a driver
is in a situation it would like more frames (which is often but not always
when there is space for one frame free) it clears dev->tbusy and does
a mark_bh(NET_BH). Since tbusy may be cleared from an interrupt handler
(consider a tx complete interrupt) it requires atomicity.
[Or in code]
if(!packet_fits(skb->len))
{
dev->tbusy=1;
return 0;
}
and in the irq handler
if(tx_completed && packet_fits(dev->mtu) && dev->tbusy)
{
dev->tbusy=0;
mark_bh(NET_BH);
}
(it can also currently be set from an IRQ - a card with LAPB in its firmware
can post "remote end sending RNR" back indicating the remote told us to
be quiet - and that is link level. Right now nothing in kernel as
standard seems to be doing that one.
> I think I'll just remove them completely, and then somebody can try to add
> them back when they have some meaning. Right now they are very obviously
If you remove tbusy your networking stops working.
> One driver doesn't much help, especially not this late in the game. I want
> a 2.2 out the door.
In which case you'll need a networking stack.
Alan
-
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/