Hello!
> That isn't/wasn't true: the protocol levels would attempt to send a timer
> based retransmission while the driver was queuing a packet. Without the
> tbusy lock the transmit routine would be simultaneously entered.
Protocol layer never tried/tries/will try to reenter to hard_start_xmit.
Listen, NEVER!
And you may be sure, that if one day it will stop to be truth,
(which is very unlikely) you will be the first, who will be asked
to approve this change. If you did not know this, then I am glad to
deliver these news to you 8).
> The queue layer has changed behavior several times over the years.
The queueing layer behaviour as seen by drivers changed last time
... (searching for the oldest kernel) ...
before linux-1.3 at least. I have no older kernels here.
> Yes, ideally the driver should never need to deal with *any* locking. It
> should return either
> "happy,happy",
> "that packet filled me up, don't send me more", or
Excellent. If you agreed, remove useless and dangerous fiddling
with dev->tbusy, please.
> "I suddenly decided I'm busy, try again later"
OK. Only one clarification is necessary, notion "later" does not exist
in kernel. There exist "now + a finite number of jiffies"
> Another place current drivers have a superfically pointless lock is the
> interrupt handler. This one is due to a bug in the SMP interrupt dispatch
> which would simultaneously enter the handler code.
This feature really existed for some time during 2.1 and it is fixed
to all that I know. It is the first.
[ Though I do not like this way very much, believing that IRQs
are not the only source of events and polling by another
threads have the same rights to exist and in some curcumstances
it is preferred way, so that locking system cannot be tied to irqs ]
The second, you added tp->interrupt lock recently, though
you were said unambiguosly that it is useless, does not solve
any real problem and you have no valid reasons to add it.
I asked you as gentleman to gentleman to preserve dev->interrupt
to make polling possible. But private lock is complete non-sense, however.
> Remember that both changing driver interfaces and introducing bugs like this
> one is *very* expensive.
What thing was changed? Nothing was changed for years.
Donald, you are unfair. Please, understand that maintaining
ecological balance is very expensive both from viewpoint of programmer
time and computer resources, but I always believed and believe now,
that the balance was never broken.
> I'm not certain what you are saying here.
OK 8) I resume it in several words: "This bug is not in drivers. Nobody
ever saw it, because it is not triggered in normal setup."
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
