I think both dev->interrupt and dev->tbusy should just go away. Both of
them are completely broken, for several reasons:
- they use up a long-word for _one_ bit of information. That's 63 wasted
bits on some architectures.
- they are incorrectly used by drivers as-is, it's better to just remove
them.
If you think we need a lock, it had better be something like "dev->flags",
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.
> In any case driver should have some lock visible from outside.
Why? I've heard this twice, and I don't see it. The upper layers need to
guarantee that the driver transmit routine is entered in a single-threaded
manner, and they already do that. The driver can then internally do
whatever further locking it needs, and return whatever status it wants to.
Right now, as far as I can see, both "interrupt" and "tbusy" are
completely unused for _anything_ sane. "interrupt" is not used at all by
the networking layer, and "tbusy" is mis-used by certain parts of the
networking layer and then used as a silly and incorrect lock by networking
drivers.
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
only confusing people, with network driver people having a completely
different idea of their use than certain network people (ank and davem),
and other network people equally obviously just not knowing what they are
there for in the first place.
> If you remember, I proposed to make one sample driver with
> really correct interface to upper and lower layers
> and to maintain it permanently, keeping it in sync both
> with networking core and with irq/smp, and, maybe, ignoring news
> on hardware market. This driver would serve as sample for driver writers.
One driver doesn't much help, especially not this late in the game. I want
a 2.2 out the door.
Linus
-
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/