Messages in this thread | | | Subject | Re: module-init-tools/udev and module auto-loading | From | Martin Schlemmer <> | Date | Mon, 02 Feb 2004 21:02:30 +0200 |
| |
On Mon, 2004-02-02 at 02:10, Rusty Russell wrote: > In message <1075674718.27454.17.camel@nosferatu.lan> you write: > > A quick question on module-init-tools/udev and module auto-loading ... > > lets say I have a module called 'foo', that I want the kernel to > > auto-load. > > The *idea* of udev et al is that the kernel finds the devices, > /sbin/hotplug loads the driver etc. >
Right.
> This does not cover the class of things which are entirely created by > the driver (eg. dummy devices, socket families), so cannot be > "detected". Many of these (eg. socket families) can be handled by > explicit request_module() in the core and MODULE_ALIAS in the driver. > Some of them cannot at the moment: the first the kernel knows of them > is an attempt to open the device. Some variant of devfs would solve > this. >
I guess there will be cries of murder if 'somebody' suggested that if a node in /dev is opened, but not there, the kernel can call 'modprobe -q /dev/foo' to load whatever alias there might have been?
Understand me correctly, I do not want devfs back. I am just checking if we could do something for similar behaviour. I know it has not _really_ hit the lists, but I have already had complaints about this not being supported anymore. I think the complaints will start even more if raminitfs eventually hits functionality (as /dev will then be then consisting only of loaded drivers (if I am not mistaken).
Once again I do not say we should give in to it, but it _does_ make things easier. So if there is a lightweight way to do this, then great - and this is what I was trying to get discussion directed to.
> > Then a distant related issue - anybody thought about dynamic major > > numbers of 2.7/2.8 (?) and the 'alias char-major-<whatever>-* whatever' > > type modprobe rules (as the whole fact of them being dynamic, will make > > that alias type worthless ...)? > > Yes. This could be changed to probe by device name, not number > though. And most names can't be dynamic: /dev/null has certain, fixed > semantics. > > The "I found this hardware, who will drive it?" mechanism of udev, and > the "User asked for this, who will supply it?" mechanism of kmod have > some overlap, but I think both will end up being required. >
Ok, was just wondering.
Thanks,
-- Martin Schlemmer [unhandled content-type:application/pgp-signature] | |