On demand modules loading with {tmp,ram}fs and udev

On demand modules loading with {tmp,ram}fs and udev

[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).

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.
-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu@irc.-nie.spam-.pl   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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: On demand modules loading with {tmp,ram}fs and udev

[Greg KH]

On Sat, Oct 25, 2003 at 02:00:18AM +0200, Tomasz Torcz wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: On demand modules loading with {tmp,ram}fs and udev

[Tomasz Torcz]

On Fri, Oct 24, 2003 at 05:42:34PM -0700, Greg KH wrote:
> On Sat, Oct 25, 2003 at 02:00:18AM +0200, Tomasz Torcz wrote:
> > 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?

Just call modprobe. Modprobe will check /etc/modprobe.conf for dsp
aliases and load module. Then udev will make devnode.
 
> 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?

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu@irc.-nie.spam-.pl   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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: On demand modules loading with {tmp,ram}fs and udev

[Greg KH]

On Sat, Oct 25, 2003 at 03:09:32AM +0200, Tomasz Torcz wrote:
> On Fri, Oct 24, 2003 at 05:42:34PM -0700, Greg KH wrote:
> > On Sat, Oct 25, 2003 at 02:00:18AM +0200, Tomasz Torcz wrote:
> > > 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?
> 
> Just call modprobe. Modprobe will check /etc/modprobe.conf for dsp
> aliases and load module. Then udev will make devnode.

Ok, that sounds reasonable.  Looking forward to your ramfs
implementation that does this :)

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel