Messages in this thread |  | | From | Herbert Rosmanith <> | Subject | Re: 1.99.14 & duplicate NE2000 | Date | 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
|  |