On demand modules loading with {tmp,ram}fs and udev
Hi,
I was thinking about small addition to tmpfs. When mounted with 'dev' option, any lookup of non existing file should result in calling modprobe with filename as argument.
When coupled with mount tmpfs over /dev (or /udev) this functionality would allow on-demand module loading (as with devfs and plain old device nodes).
On #kernelnewbies I was told to use ramfs (as device nodes don't have to be swap bakced). But it looks like polluting simple ramfs with this mount option is not good. Is using tmpfs OK?
please cc me on comments.
Signature · 14 lines
Tomasz Torcz There exists no separation between gods and men: [email protected] one blends softly casual into the other. |> Playing: ... ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Tomasz Torcz
Hi,
I was thinking about small addition to tmpfs. When mounted with 'dev' option, any lookup of non existing file should result in calling modprobe with filename as argument.
When coupled with mount tmpfs over /dev (or /udev) this functionality would allow on-demand module loading (as with devfs and plain old device nodes).
How will you do the mapping of /dev names to modules in kernel space?
How are you going to know which of the 50 or so sound drivers to load when opening /dev/dsp?
And what's wrong with the current scheme of, "load a driver when the device is seen"? This is how Linux currently works, and has been moving to for quite some time. In the past we didn't have that capability, so the "load the driver when we open the /dev node" hack was added.
Remember, the current size of most /dev trees is about 18 thousand entries and growing...
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Greg KH
Quoted 8 lines · Tomasz Torcz
Hi,
I was thinking about small addition to tmpfs. When mounted with 'dev' option, any lookup of non existing file should result in calling modprobe with filename as argument.
When coupled with mount tmpfs over /dev (or /udev) this functionality would allow on-demand module loading (as with devfs and plain old device nodes).
Quoted 3 lines
How will you do the mapping of /dev names to modules in kernel space? How are you going to know which of the 50 or so sound drivers to load when opening
/dev/dsp?
Just call modprobe. Modprobe will check /etc/modprobe.conf for dsp aliases and load module. Then udev will make devnode.
Quoted 4 lines
And what's wrong with the current scheme of, "load a driver when the device is seen"? This is how Linux currently works, and has been moving to for quite some time. In the past we didn't have that capability, so the "load the driver when we open the /dev node" hack was added.
Few days ago I did dd if=something of=/dev/floppy/0; then I saw in logs that floppy module was loaded. That was because I use devfs which run modprobe when it's needed.
With udev dd would fail with non-existant /dev/floppy/0. There is no mechanism to call modprobe.
I'm also surprised that"load the driver when we open the /dev node" is a hack. I get used to this standard Linux functionality as something obvious. Other OSed (*BSD, Solaris etc.) don't work like that?
Signature · 14 lines
Tomasz Torcz There exists no separation between gods and men: [email protected] one blends softly casual into the other. Please CC. ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Tomasz Torcz
Quoted 10 lines · Greg KH
Quoted 8 lines · Tomasz Torcz
Hi,
I was thinking about small addition to tmpfs. When mounted with 'dev' option, any lookup of non existing file should result in calling modprobe with filename as argument.
When coupled with mount tmpfs over /dev (or /udev) this functionality would allow on-demand module loading (as with devfs and plain old device nodes).
Quoted 6 lines
Quoted 3 lines
How will you do the mapping of /dev names to modules in kernel space? How are you going to know which of the 50 or so sound drivers to load when opening
/dev/dsp?Just call modprobe. Modprobe will check
/etc/modprobe.conffor dsp aliases and load module. Then udev will make devnode.
Ok, that sounds reasonable. Looking forward to your ramfs implementation that does this :)
Quoted 4 lines
I'm also surprised that"load the driver when we open the /dev node" is a hack. I get used to this standard Linux functionality as something obvious. Other OSed (*BSD, Solaris etc.) don't work like that?
I do not know what other oses do in this regard, sorry.
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel