Re: 1.99.14 & duplicate NE2000

Herbert Rosmanith (herp@wildsau.idv.uni-linz.ac.at)
Sun, 9 Jun 1996 21:04:56 +0200 (MET DST)


> > insmod /lib/modules/1.99.14./net/ne.o io=0x340
> > this is of course not correct. 0x340 is already being used by eth0.
>
> Yes, you can force the ne module on top of an already in-kernel driver.
> And you can re-load the module on top of the other module as well to
> get you an eth3, eth4 and so on. It isn't limited to the ne driver. It
> isn't even limited to ethernet drivers either. Oh, and it isn't even
> limited to modules, meaning you can do the same type of insane things at
> boot as well. (Bet you didn't know you could do this... :-)
right, I didn't ...

> foobar# cat /proc/cmdline
> BOOT_IMAGE=test ro root=802 ether=9,0x240,eth0 ether=7,0x240,eth1 ether=5,0x240,
> eth2
> foobar# dmesg|grep WD8
> eth0: WD80x3 at 0x240, 00 00 C0 4E DC 52 WD8003, IRQ 9, shared memory at 0xe800
> 0-0xe9fff.
> eth1: WD80x3 at 0x240, 00 00 C0 4E DC 52 WD8003, IRQ 7, shared memory at 0xe800
> 0-0xe9fff.
> eth2: WD80x3 at 0x240, 00 00 C0 4E DC 52 WD8003, IRQ 5, shared memory at 0xe800
> 0-0xe9fff.
> foobar#
> -----------------------
>
> No, this is *NOT* a bug. It is a feature. The "reserve=" boot keyword,

hm .... a feature ? I don't want to be impoilte, but I think it's a
design flaw ...

> linux reserve=0x300,0x20 ether=0,0x300,eth0
[...]
> The "reserve=" doesn't do any magic. It just puts a dummy entry
> (a placeholder) into the ioport table, which will block all auto-probes

when an OS can stop the sysop to do stupid things, it should do so, imo.
don't! trust the operator ! here we have a saying: "trust is good,
controlling is better"....

if you allow multiple "request_region", one dummy (or in the kernel), the 2nd
for real, then the following problem can happen: when you remove the 2nd
module, the region will be freed, allthough there still is one "entity"
which has a request_region still open. the device will still be in
your list of configure eth-devs (ifconfig), but it will not be in
/proc/ioports anymore.

the need to reserve regions to stop other drivers from autoprobing in there
could be handled in a different way then... probably a "region use counter",
allthough this sounds like an overkill. what about a "triple state" variable.

a region can have three states:
+ unassigned
+ reserverd
+ assigned

a driver, that does an autoprobe, must neither probe in "reserved", nor
in "assigned" regions.
a driver, that does a specific probe, is allowed to probe in "reserverd"
regions. however, it is not allowed to probe in "assigned" regions.

i think this is a cleaner way to handle the problem of io-region allocation,
plus allowing them to be reserved for later use.

comments ?

additionally, one could make "request_region" terminate the calling process
in case the region is already assigned. this way, "insmod" wouldnt have
a chance to continue and leave the system in a messy state.

/herp