From: Nigel Kukard <nkukard@lbsd.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev 145, when are events fully processed?
Date: Fri, 07 Aug 2009 16:10:47 +0000 [thread overview]
Message-ID: <4A7C5207.5020507@lbsd.net> (raw)
In-Reply-To: <4A749D9E.3020709@lbsd.net>
Alan Jenkins wrote:
> On 8/7/09, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> On Fri, Aug 7, 2009 at 16:48, Nigel Kukard<nkukard@lbsd.net> wrote:
>>
>>
>>> I have a nice C proggie I'll including in bootutils, unless you guys are
>>> interested in including it in udev?. Attached for anyone interested,
>>> with timeout support. It can wait for a device or labeled device to come
>>> up :)
>>>
>> It looks fine, but I guess it does nothing really else than:
>> udevadm settle --exit-if-exists=/dev/disk/by-label/foo
>>
>
> I think that still exits as soon as the queue becomes empty. Isn't
> there a problem with usb devices being probed asynchronously?
>
> I'm thinking of the "rootwait" problem. The problem that is addressed
> in-kernel by the "initdev" patches. Doesn't userspace (initramfs)
> still have to deal with that?
>
I think you guys are missing the problem I'm having. This has nothing to
do with USB, I don't use USB and don't load any USB modules. I've tried
this out on 3 boxes using kernel 2.9.29.6 and udev 145.
Here are the modules loaded ...
ahci, piix, ide_core, ata_piix, pata_acpi, libata
* I have a kernel with an initramfs, no disk controller modules are
loaded at all before the initramfs fires up
* My script is this ....
examine pci bus & modprobe modules we need for disks
fire up udev
udev trigger
udev settle
mount LABEL=root
Simple. Now .... that works in 141 fine, it does not in 145. If I do an
ls /dev straight after settle, there are no sd* devices. If I add a
sleep 5s after settle, the devices are there.
udevadm settle exits after about 1 second, when I check the creation
times on the devices it takes a few seconds, up to 5 depending on the
speed of the box.
Kay, you said yourself that settle does not wait until the events are
fully processed and exits once they have been recieved by udev. This is
EXACTLY what is happening in 145. You further said this is due to the
speed improvements with 145 and I was just lucky in 141 and I should be
waiting for the udev event that the device has been processed. I went
over the chat logs again to make sure I'm not imagining things.
This will not work ... udevadm settle
--exit-if-exists=/dev/disk/by-label/foo , 'udevadm settle' exits
BEFORE the device is created.
next prev parent reply other threads:[~2009-08-07 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-01 19:55 udev 145, when are events fully processed? Nigel Kukard
2009-08-07 12:26 ` Harald Hoyer
2009-08-07 12:56 ` Nigel Kukard
2009-08-07 14:15 ` Alan Jenkins
2009-08-07 14:48 ` Nigel Kukard
2009-08-07 15:34 ` Kay Sievers
2009-08-07 16:00 ` Alan Jenkins
2009-08-07 16:10 ` Nigel Kukard [this message]
2009-08-07 16:24 ` Kay Sievers
2009-08-07 16:40 ` Nigel Kukard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A7C5207.5020507@lbsd.net \
--to=nkukard@lbsd.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).