[1571] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Network device setup (was Re: unresolved register_netdev() in 52)

daemon@ATHENA.MIT.EDU (Avery Pennarun)
Tue Jan 2 02:33:36 1996

Date: 	Mon, 1 Jan 1996 19:52:19 -0500 (EST)
From: Avery Pennarun <apenwarr@foxnet.net>
To: Paul Gortmaker <gpg109@rsphy1.anu.edu.au>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <9512310548.AA21707@rsphy6.anu.edu.au>

On Sun, 31 Dec 1995, Paul Gortmaker wrote:

[...]
> Now, the register_netdev() calls were originally intended to be for use
> within init_module() and cleanup_module() routines only. However some
> recently added 1.3.x drivers have broke this assumption. These are:
> pi2.c, pt.c, and arcnet.c -- they use the following method:
> 
> 2) Put a semi-bogus static dev into Space.c to hook the driver probe
>    into the probe sequence, or put the probe call directly into
>    core/dev.c (pi2, pt) Then kmalloc a "dev" sized chunk of memory, 
>    or declare it static, from within the driver itself. Then fill in
>    some of the fields, and call register_netdev() to squeeze it into the
>    linked list. Then register_netdev() calls dev->init(dev) itself
>    to see if the device comes up.
[...]

I, as the author of arcnet.c, thought it was a great idea at the time, and I
still do.  It seemed the best way to handle multiple different TCP/IP
protocol encapsulations on the same card.  Eventually I want to make each of
these encapsulations individually selectable at compile time and I wanted to
keep as much junk as possible out of other kernel files.  Currently arcnet.c
is entirely self-contained (which is not necessarily a good thing either).

If there is a better way to do this, tell me quick!  Right now I'm having
some problems with multiple-simultaneous flood pings on more than one
different arcnet device (ie. arc0e and arc0s) blocking each other. 
Interestingly, the first device registered will work fine while later
devices are blocked.  To be more specific:
	- arc0 (RFC1201) is in Space.c (which reminds me, there should be an
	  arc1 and arc2 etc in Space.c like with ethernet)
	- ifconfig arc0 up
	
	- arc0e (ethernet-type encapsulation) and arc0s (RFC1051) are
	  registered, in that order.
	- ifconfig arc0s up
	- ifconfig arc0e up
	- ping -f computer-via-arc0s
	- ping -f computer-via-arc0e
	
Upon executing the second ping, all packets cease to be sent out arc0s, as
it was registered last.  This is not related to anything but the
registration order; switching around the two blocks in arcnet.c will cause
arc0e to stop sending instead.

"ping -f computer-via-arc0" takes precedence over both of the others, ie.
the other stop.

Just thought I'd bring that up while I was thinking of it :)

> Anyway, the point I am getting at here, is that there is duplicate
> functionality and room for a clean up between net_init.c, Space.c and 
> net/core/dev.c and I would like to tidy this up eventually, but in the 
> meantime, this tiny tweak will allow people using the above drivers to 
> link with CONFIG_MODULES set to N.

Of course, you still need something like Space.c to do the probing before
register_netdev will ever be called, if modules aren't being used.  It's
hard to win :)

Oh, by the way, whatever happened to the patch that added a "kick me"
function call to all the network drivers?  I remember there was a patch for
this in 1.2.x during the old 1.3.6-or-so days.

Have fun.

Avery



home help back first fref pref prev next nref lref last post