* [Proposal] Handle multiple /sys-like dirs
@ 2004-02-29 12:35 Alexander E. Patrakov
2004-02-29 13:01 ` Olaf Hering
0 siblings, 1 reply; 2+ messages in thread
From: Alexander E. Patrakov @ 2004-02-29 12:35 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-02-29 13:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-29 12:35 [Proposal] Handle multiple /sys-like dirs Alexander E. Patrakov
2004-02-29 13:01 ` Olaf Hering
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).