netdev
[Top] [All Lists]

Re: 3c59x.c

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: 3c59x.c
From: Donald Becker <becker@xxxxxxxxx>
Date: Tue, 28 Mar 2000 12:32:01 -0500 (EST)
Cc: Alexey Kuznetosv <kuznet@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <38E0C957.8BEE9D05@uow.edu.au>
Sender: owner-netdev@xxxxxxxxxxx
On Tue, 28 Mar 2000, Andrew Morton wrote:

I can answer the two questions that are historical.

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

Because they are semi-broken.  Someone, I don't recall the details,
converted drivers to modules.  But they had the perspective that only one
card of each type might exist.  One of the few correct drivers in this
respect is the znet.c driver, where only one device can exist.  (It uses
*two* DMA channels and only had a on-motherboard implementation.)

Calling init_etherdev() to get a dynamically allocated device is the correct
approach.  Ideally the driver interface would have been defined to always
use this mechanism, but that wouldn't work with compiled-in drivers that took
LILO parameters.  By the time LILO parameters became more flexible, the
limited "drivers/net/Space.c" configuration was too well established in the
documentation.

> - Why do some go (in probe1):
> 
>   if (dev == NULL)
>       init_etherdev()
> 
> whereas others do not test for null?  Is the test necessary?

No.  The init_etherdev() call should work for both NULL and partially
pre-allocated parameters.  If NULL, it should return the "next" device (a
struct net_device).

It's not assured, but the intent is that it will return the first unused
device from {"eth0" "eth1"...}.  If preallocated, the structure is
initialized for a generic Ethernet-like interface.  Devices that approximate
Ethernet (e.g. wireless cards, PLIP, USB links) should use this interface
and tweak the parameters rather than writing their own init_*() routine.

The second parameter is the size for allocating a dev->priv region.  In
general using this feature is depricated.  One reason is the alignment and
memory region attributes of the dev->priv region is historically
unpredictable.  You should pass '0' and allocate dev->priv yourself.

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

I think that this new behavior is bogus.  Multiple calls should only occur
for ISA drivers that have previously reported that they found a card.  The
PCI et al. driver scan routines should only be called once.

Donald Becker
Scyld Computing Corporation, becker@xxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>