[lkml]   [1998]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tulip driver in 2.1.11* - 2.1.21 is broken - new driver

> 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.

Certainly. It was not made during 2.1 by the only reason: it would require
lots of microscopic changes in all the drivers and would broke drivers
maintained separately f.e. by Donald.
This situation is the same as with the second argument to kfree_skb(), it
was dead for more than year, but it existed until you were tired to see it 8).
Only real master (you know who 8)) may schedule such kind of change.

> - they are incorrectly used by drivers as-is, it's better to just remove
> them.

tbusy is used correctly (with one known exception: ppp),
it always was main element of queuing engine and it is not required
to be atomic. Another thing is that drivers do useless atomic operations on it.

> 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.

tbusy cannot be removed without destruction of all the networking.
It may be not atomic, but some device drivers (by a mistake) do
atomic operations on it. The situation is obscured a bit by the fact
that some drivers make wrong assumption, that tbusy is some tx lock.
It is wrong assumption, but it is harmless.

> > 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.

It is fastroute. Fastroute enters to transmit routine from interrupt
of another card. The most interesting fact is that it is not revolution.
It does require only a bit more accurate programming of driver,
which is done for tulip and 8390 for now. But it is transparent
and may be added incrementally (and maintained separately),
provided drivers export dev->interrupt.
For now, fastroute is the only way to forward on 100Mbit interfaces.

> One driver doesn't much help, especially not this late in the game. I want
> a 2.2 out the door.

Well, drivers are written permanently not depending on current version
stamp on kernel. Now people clone from some random driver,
mainly from Becker's ones. I do think, that one "official" driver
should be selected, audited (and fixed) to reflect current irq/smp paradigm.
Certainly, massive fixing drivers/net/* may be deferred to later.
Actually, there is one problem now, which makes this discussion
academic. We stand on the edge now. Seems, it is not widely known
fact, but current Linux CANNOT handle >~100Mbit interfaces.
Comparing to bsd and even NT we have too high minimal latency.
Particularly, 1Gb ethernet with mtu 1500 is death for Linux
on 200-300MHz P-II, we will lose all 100% of packets there.
This aspect is not well investigated yet, at least, seems nobody
but me tried to undrstand, why it occurs.
In any case, it is very probable, that solution of this problem
will make all the problems with dev->interrupt etc. ridiculous.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans