Re: udev 070 not create dvb device

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Oct 27, 2005 at 08:48:10PM +0600, Alexander E. Patrakov wrote:
> 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?

I should be easy, as it's almost the same as "udevsynthesize", which
works already good enough.

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

I have it running without udevstart. You just need to create a few
nodes. And you need to start the daemon and may want to disable
/sbin/hotplug (if you have the input fixes, or can live without input events)

> 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?

Well, we are in the middle of finding that out. It was a long way,
SUSE today stores all events in initramfs to be replayed after the root
is mounted. That works pretty well so far, but the "uevent" trigger by
sysfs sounds nicer, cause it works with every kernel and without a
special prepared initramfs.
We'll see, nobody knows how exactly it will look like, but it already
looks better than everthing we've had in the past. :)

Kay


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