Great!
I think Linux approach with probing and initializing devices when a
module is inserted in the kernel sucks.
Maybe suck is a strong word, but some things would have been easier
if the driver had some kind of configuration call or /proc entry which
userspace configuration software could talk to.
problem 1: laptop with pcmcia-cs package.
1. No pcmcia cards inserted.
2. A network card is inserted and the driver abcd.o is loaded into the kernel.
The network is configurated and traffic is started.
3. Another identical network card is inserted.
What to do? Should we take down the traffic, remove abcd.o and insmod it again?
I like the idea of a huge database with vendor id:s and device id:s.
Both pcmcia and pci should use the same approach.
In the startup scripts, some userspace code parses /proc/bus/pci and
the pcmcia slot info and finds what modules should be loaded.
Then the script insmods the needed modules. great.
problem 2: any pc with multiple network cards: configuration
1. Say you have 3 network cards in your machine:
device 1: 3com 3c590
device 2: dlink
device 3: 3com 3c590
2. Drivers are inserted in the kernel.
The 3com cards share the same driver.
If we insert the 3com driver first we get the following:
eth0 3com (dev 1), eth1 3com (dev 3), eth2 dlink.
If we insert the dlink driver first we get something like this:
eth0 dlink, eth1 3com (dev 1), eth1 3com (dev 3).
I would like to have control over my system!
Sure, I could just accept the fact that each driver probes and assigns
on it's own.
But I would like to have eth0 at dev 1, eth1 at dev 2, eth2 at dev 3.
Or user-selectable:
eth0 at 08:00:12:34:56:78 and eth1 at 08:01:12:34:56:78, etc.
If the drivers could be initialized from userspace after insertion
those problems could be avoided.
The same hotswap problem must exist in the usb world, right?
Cheers /
Magnus Damm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/