[Proposal] Handle multiple /sys-like dirs

[Proposal] Handle multiple /sys-like dirs

[Alexander E. Patrakov]

Hello list,

Recently I complained about the "chicken-and-egg" problem with modules that 
represent not a piece of real hardware, but some abstraction (like loop, lp, 
pktcdvd, ppp_generic,...) and modules that correspond to undetectable 
hardware (e.g. floppy). The problem is in the FAQ and is related with the 
module autoloading. E.g., /dev/loop0 does not exist until someone does a 
"modprobe loop", and there is no means to load that module automatically when 
an application tries to open /dev/loop0.

The answer given was to pre-create /dev/loop0 from an initscript, so that the 
"loop" module will be inserted via the usual "block-major-7-*" alias 
in /lib/modules/`uname -r`/modules.alias. Marco d'Itri admitted that this 
solution is rather ugly. In fact it returns us to the static /dev directory. 

I propose another solution. It will require some cooperation from the kernel 
build process, but I want to discuss it here before posting to LKML, because 
I am not a kernel hacker.

The solution is to allow several /sys-like directory hierarchies. One of them 
is the usual sysfs. Another one will be put into /lib/modules/`uname -r`/sys 
and will be populated during "make modules_install" step and will contain the 
files identical to those which would appear in /sys after a module gets 
probed. E.g., there will be:

/lib/modules/2.6.3/sys
	block
		loop0
			dev (contains "7:0")
			range (contains "1\n3")

and so on. Probably a new macro like

MODULE_SYSFS_STUB("block/loop0/dev", "7:0")

will be needed, which would add the strings to a special section of the 
module. Note that this section should not be present in modules that require 
some hardware to work properly, because hardware is usually detectable and 
the usual coldplug script will insert them.

Then, we will just need the udev initscript instruct udev to take the entries 
first from /lib/modules/`uname -r`/sys and then run_udev against the 
usual /sys. This can be done using an environment variable.

The udev initscript will thus create /dev/loop0 and other undetectable devices 
that require a module to be loaded, and then the usual "block-major-7-*" 
magic will work.

Also consider something like /etc/udev/sys with a sysfs-like hierarchy created 
by the administrator for site-local needs.

This approach is better than untarring a tarball or issuing a series of mknod 
commands because:

1) The renaming rules in /etc/udev/udev.rules can be applied against those 
kernel-generated device names in modules, thus supporting both LSB-styled and 
devfs-styled device names.
2) All device permissions are stored in one file /etc/udev/udev.permissions

If you think that this idea is worth implementing, please express your 
detalisations, corrections, objections, etc. before I pass it onto LKML.

Or just say that the idea is completely wrong :)

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
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: [Proposal] Handle multiple /sys-like dirs

[Olaf Hering]

has any of you module-on-demand-loaders compared the memory foot print
of a kernel without all these char-major-foo strings and the module
autoloader and one kernel where you load all modules manually because
you know you will need them?
autoloading makes eventually sense for netfilter, but for the rest?
probably not.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n√úRNBERG


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
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