netdev
[Top] [All Lists]

Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)

To: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
From: Paul Gortmaker <p_gortmaker@xxxxxxxxx>
Date: Mon, 06 Nov 2000 02:55:13 -0500
Cc: Donald Becker <becker@xxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <Pine.LNX.4.10.10011021935530.11540-100000@xxxxxxxxxxxxx> <3A020C19.4C4B3F66@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Jeff Garzik wrote:
> 
> Donald Becker wrote:
> > Most people with multiple network adapters use the same board type.  Seeing
> > a list of identical board names isn't very useful when you are trying to do
> > something like map interrupt counts to interface statistics.
> 
> You're talking about request_irq not request_region here, and
> /proc/ioports isn't as "actively useful" as /proc/interrupts.
> 
> But you do have a point -- It sounds more informative to have dev->name
> in /proc/ioports for the multiple ISA adapters case as well.  Seeing
> "3c509" twice in /proc/ioports is not as informative (IMHO) as knowing
> that eth0 is at 0x300 and eth1 is at 0x320.  Further, using dev->name in
> request_region means that we have consistency with request_irq usage.

Something to consider (while still restricting this discussion to ISA
junk), you can always get ethN <---> irq/ioport mapping via. SIOCGIFMAP.
But the only reliable way to query the kernel as to what compiled in ISA
net driver is installed is by a model name in /proc/[ioports,interrupts]
(Yes, I know, a minor issue...)

Also, the trend for /proc/ioports (and interrupts) in other parts of the
kernel still appears to be based on hardware/model names and not kernel
device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
be consistent?

> The only downside to using dev->name is that some drivers currently
> touch the hardware before they have an interface name, but that is not a
> real problem at all.

Yes, not a problem  - these can be handled with something like:

 struct resource *r;
 if ((r = request_region(..., "foo-probe")) == NULL) return -EBUSY;
 ret = foo_probe(...);
 if (ret != 0) release_resource(r);
 else r->name = dev->name;
 return ret;

Paul.


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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