Alexey Kuznetosv wrote:
> > The other is to actually understand what is going on. AFAIK there is no
> > description of the softnet<->driver interface which allows driver
> > writers to gain this understanding. A simple functional API description
> > doesn't cut it - we need to know what the dynamic relationships are,
> > what serialisation guarantees the higher layer makes, etc.
> Jamal's document covered all the _necessary_ topics with
> pretty deep explanations. If you have something to add to the list
> of "necessary" topics, please, add.
Sorry, I guess I was venting a little frustration. As an experienced
system programmer (20 years. gad.) I _expect_ to be able to pick up the
architectural aspects quickly but after quite a few evenings work I keep
on finding surprises in this stuff. Getting old, I guess.
> > Yes, I know of davem's email and Jamal's doc. They're not enough. The
> > lack of this architectural description will adversely affect Linux's
> > overall quality. Is doing so, in fact.
> Ask some concrete questions better. All such documents are result
> of dialogue, rather than broadcast from a godlike being.
> No questions --- no answers.
mm.. The problem with this approach is that it doesn't scale. _I_
learn the answer, and then the next person comes along...
Here are a few:
- Why do some drivers statically allocate their struct net_device
(eepro, cs89x0) whereas others call init_etherdev()? What's the right
thing to do?
- Why do some go (in probe1):
if (dev == NULL)
whereas others do not test for null? Is the test necessary?
- The manipulation of the pci_root_buses and pci_devices lists in pci.c
has no SMP or IRQ protection. The net drivers call into pci.c to
add/remove things from these lists but provide no race avoidance. Is
there something higher up which guarantees that these list operations
are serialised wrt some random soundcard driver or is this a bug?
- As far as I can tell, many Ethernet chips separate the Tx and Rx
functions sufficiently well for the driver author to be able to let the
Tx and Rx threads operate independently. And the orginal architecture
allowed this to occur.
But the recommended practice of locking the whole driver within
hard_start_xmit() will penalise the Rx threads.
If this is correct, should we be using separate rx and tx device-private
- Should we be hardwiring ISAPNP databases into the drivers? Shouldn't
these be on disk? (this question is rhetorical - I don't think anyone's
interested in ISA any more).
A lot of these questions would be perfectly answered if someone such as
yourself were to give the skeleton driver an overhaul. Then if any
drivers deviate from its recipe we need to understand why.
> BTW why did you have no questions before softnet? 8)
I've only been looking at this stuff for a few weeks. When Alan marked
the cs89x0 driver as 'OBSOLETE' I had to get involved. That thing cost
me nine bucks!
BTW: a while back I noticed that the driver's probe1() is being called a
huge number of times at bootup from net/dev.c. Is this known about?
[ Shit. I haven't done any work on this today. I learnt quite a bit
about IDE tho :-) ]