Re: udev 070 not create dvb device

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

Kay Sievers wrote:

>On Thu, Oct 27, 2005 at 10:28:54AM +0600, Alexander E. Patrakov wrote:
>  
>
>>Kay Sievers wrote:
>>
>>    
>>
>>>You may try something stupid like this:
>>>
>>>while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') 
>>>-gt 1 ]; do
>>>    sleep 0.1
>>>done
>>>
>>>
>>>      
>>>
>>1) This can be simplified to:
>>
>>while pidof udevd | grep -q " " ; do
>>     sleep 0.1
>>done
>>    
>>
>
>No, that will not catch the "udev" processes. We need to catch both,
>cause only the "rules-in-daemon" patch forks "udevd" processes.
>  
>
Then:

while pidof udev udevd | grep -q " " ; do
     sleep 0.1
done

:)

>>2) Greg KH said to stick with (synchronous) udevstart for now, and I 
>>agree with him here. But there's your comment at 
>>http://bugs.debian.org/329226
>>
>>    
>>
>>>That's one of the problems with a synchronous udevstart. It should go
>>>away for a lot of other reasons too and I refused all the "coldplug"
>>>patches for udevstart for that reason.
>>>
>>>
>>>      
>>>
>>That seems to be in disagreement with Greg's words. Is that viewpoint 
>>obsolete?
>>    
>>
>
>No, thats fine. It depends on how you set-up your booting and it's a safe way
>to do it for now.
>  
>
OK. I see: for now, the recommended and safe way to populate /dev is to 
run udevstart.

>>Or are there still plans to drop synchronous udevstart
>>    
>>
>
>Sure, I'm currently working on a sysfs triggered, kernel based hotplug:
>  http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/coldplug-emit-hotplug-events-from-sysfs.patch
>
>  
>
Thanks, now I know where to get the latest version of this patch.

>>and make this "pidof" hack (or something equivalent) the official 
>>recommended solution?
>>    
>>
>
>We'll see ...
>  
>
I interpret that as "nothing better has been invented yet for use with 
that patch but this situation may change". Am I right?

Anyway, I think that the following will work safely enough if one 
ignores the input subsystem:

1. Apply that kernel patch, add udev rules for modaliases and firmware, 
build the relevant extras. Install updated module-init-tools for 
blacklist support. Do not install hotplug.
2. In S00mountkernfs initscript, mount /proc and /sys as usual.
3. In S10udev initscript, mount tmpfs on /dev, run "UDEV_RUN=0 
/sbin/udevstart" and create additional directories and symlimks in /dev. 
For Matthew: it is the same as the default udev initscript in LFS does, 
but with UDEV_RUN=0.
4. In S40mountfs initscript, mount /usr and the rest of filesystems, as 
usual.
5. In the new S55coldplug-emit initscript (to be used instead of 
S55hotplug), do those echoes to "uevent" files in sysfs. Thus, modules 
will be loaded, devices will be created (yes, udevstart's work 
duplicated) and RUN rules will be also applied.

Benefit for BLFS: those RUN rules will be applied with /usr certainly 
mounted, thus there's no longer any need to wait for /usr in the alsa 
RUN helper.

Kay, could you please look at this and tell if anything is certainly 
wrong/unsafe/bad except for the input subsystem?

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
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