From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alexander E. Patrakov" Date: Thu, 27 Oct 2005 14:48:10 +0000 Subject: Re: udev 070 not create dvb device Message-Id: <4360E8AA.6030405@ums.usu.ru> List-Id: References: <20051015141800.26330.qmail@web34812.mail.mud.yahoo.com> In-Reply-To: <20051015141800.26330.qmail@web34812.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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