Re: Non-hardware devices like loop: another idea

["Alexander E. Patrakov" <patrakov@ums.usu.ru>]

Mike Snitzer wrote:

>On Tue, Mar 16 2004 at 21:13,
>Alexander E. Patrakov <patrakov@ums.usu.ru> wrote:
>
>  
>
>>On Wednesday 17 March 2004 06:47, Mike Snitzer wrote:
>>    
>>
>>>What if you configure this options into the kernel, e.g.:
>>>
>>>CONFIG_BLK_DEV_LOOP=y
>>>CONFIG_TUN=y
>>>... etc ...
>>>
>>>rather than building all non-hardware backed devices as modules?  Relying
>>>on them being modules seems quite restrictive.
>>>
>>>Mike
>>>      
>>>
>>This will also work. If you do so, then the corresponding entries will not 
>>appear in the "modules.alias" file.
>>    
>>
>
>Right; they won't appear in modules.alias and therefore your solution
>won't work.
>
>  
>
>>Also, I don't completely understand you when you say that something relies 
>>upon these options being modules. Can you explain it more clear?
>>    
>>
>
>You were suggesting that modules.alias and modules.conf be parsed to
>determine which non-hardware backward devices should get created by udev.
>By the nature of these module related files; it implies those options be
>configured as modules, no?
>
>So I suppose what you're suggesting _could_ work (if modules) but its not
>a complete solution.
>  
>
Now I see where the confusion comes from. You misunderstood my proposal. 
Sorry for not making it clear enough.

I don't propose to parse these files at all. I want to probe the modules 
corresponding to the *-major-* aliases unconditionally. Let's review the 
scenarios for the loop module.

1) It is in the kernel. Then the /sys/block/loop0/dev file will be 
present upon boot, the udev initscript as supplied with the current 
version of udev will notice it while walking the /sys/block hierarchy, 
and /dev/loop0 will be created from the initscript.

2) It is a module. Then the modified initscript will notice that there 
is a block-major line in /lib/modules/<version>/modules.alias with the 
"loop" as its third field. You suggest to create /dev/loop0 based on 
this information. I suggest to just call "modprobe loop" instead. The 
kernel will send the hotplug event and the udev program as supplied in 
the current udev package will react upon that event by creating /dev/loop0.

As you can see, looking at modules.alias and modprobe.conf is just a 
good (?) heuristic that helps to decide which modules don't depend upon 
some specific hardware and therefore are not detectable by the current 
hotplug package.

The question mark above is because of the ide-cd module: it is not 
detectable by hotplug and doesn't have a standard alias in modules.alias.

-- 
Alexander E. Patrakov



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&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