> > 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.
>
[...]
I think it would be nice if the access to these fields was
encapsulated in clearly named inline functions for 2.3, and they are not
touched by anything else. If we have well defined interfaces the misuses
that are complained about won't happen :)
Something like:
/* Tell higher layer to stop putting new data */
static __inline__ void device_xoff(struct device *dev)
{
dev->tbusy = 1;
}
/* Tell higher layer to start transmitting again */
static __inline__ void device_xon(struct device *dev)
{
if (dev->tbusy) {
dev->tbusy = 0;
mark_bh(NET_BH);
}
}
It is probably even worth to make them non-inline to get a more stable
network driver module binary interface in the long run.
-Andi
-
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/