linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* udev + modprobe.conf
@ 2004-02-23 12:20 Alexander E. Patrakov
  2004-02-23 15:01 ` Daniel Drake
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Alexander E. Patrakov @ 2004-02-23 12:20 UTC (permalink / raw)
  To: linux-hotplug

Hello,

I have my /dev on tmpfs managed by udev-018 (I use an initrd to mount that 
tmpfs and populate it before the real init starts). It works, but there are 
questions.

1) I put the following two lines into udev.rules instead of the default cdrom 
rule:

BUS="ide", KERNEL="*[!0-9]", PROGRAM="/bin/cat /proc/ide/%k/model", 
	RESULT="PHILIPS CDD5301", NAME="%k", SYMLINK="cdrw"

BUS="ide", KERNEL="*[!0-9]", PROGRAM="/bin/cat /proc/ide/%k/model", 
	RESULT="SAMSUNG CD-ROM SC-148F", NAME="%k", SYMLINK="cdrom"

(sorry, they wrapped). Currently, the Philips drive is /dev/hdd and Samsung 
is /dev/hdb. The symlinks work as expected, but I also want to have 
a /dev/dvd symlink pointing to the Philips drive, in addition to the 
existing /dev/cdrw symlink pointing to it. How can I do that?

2) udev works perfectly for devices that have some detectable hardware 
corresponding to them, e.g. for PCI soundcards, agpgart, and so on. The 
hotplug script detects the hardware at boot time, loads the module, and then 
udev creates the device in /dev, so that this piece of hardware becomes 
accessible.

But there are some modules that correspond not to real detectable hardware, 
but to some abstract entities, e.g. "ppp_generic" and "loop". I know that the 
FAQ says

   Such a functionality isn't needed on a properly configured system. All
   devices present on the system should generate hotplug events, loading
   the appropriate driver, and udev will notice and create the
   appropriate device node.  If you don't want to keep all drivers for your
   hardware in memory, then use something else to manage your modules
   (scripts, modules.conf, etc.)  This is not a task for udev.

The point is that the answer is probably incorrect. This is probably not the 
task of udev, but this is not solvable with modules.conf. Let's review two 
situations corresponding to older methods of managing /dev and loading 
modules, using the "loop" module as an example.

a) Static /dev. The "mount" program tries to open /dev/loop0 (it exists, has 
the major number 7 and the minor number 0). The kernel sees that this /dev 
entry has no driver associated with it and tries to modprobe "char-major-7". 
And this is handled using modprobe.conf.

b) devfs. The "mount" program tries to open /dev/loop0 (it does not exist). 
Since devfs is very special, the kernel notifies devfsd about that. devfsd 
tries to probe the module named "loop".

The end result in both cases is that the "loop" module gets loaded, the "open" 
syscall succeeds, and the chicken-and-egg problem gets solved. This is not 
the case for udev. Yes, I know that the FAQ says

   The devfs approach caused a lot of spurious modprobe attempts as
   programs probed to see if devices were present or not.  Every probe
   attempt created a process to run modprobe, almost all of which were
   spurious.

Do I understand correctly that the "char-major-..." business deserves the same 
attitude? If it does, please state it in the FAQ and remove the reference to 
modprobe.conf from the previous answer. Also, doesn't this behaviour happen 
with static bloated /dev directories of distros when a program tries to 
figure out how many soundcards are installed?

If I am wrong, please point me to a correct way of loading the "loop" module. 
If the answer is "preload it and all other non-detectable modules at boot 
time with modprobe -a -t '*'", then my viewpoint is that we are returning 
back to non-moduar Linux-1.2.x this way. So please suggest something 
different.

-- 
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] 5+ messages in thread
end of thread, other threads:[~2004-02-28  0:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-23 12:20 udev + modprobe.conf Alexander E. Patrakov
2004-02-23 15:01 ` Daniel Drake
2004-02-23 16:23 ` Alexander E. Patrakov
2004-02-24 12:12 ` Marco d'Itri
2004-02-28  0:24 ` Greg KH

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