All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>
To: Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Cc: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: initqueue
Date: Thu, 2 Jul 2009 15:45:56 +0200	[thread overview]
Message-ID: <4A4CBA14.7010301@bfh.ch> (raw)
In-Reply-To: <4A4CAD6F.6080201-l3A5Bk7waGM@public.gmane.org>

Hannes Reinecke wrote:
> Hi all,
> 
> Seewer Philippe wrote:
>> Harald Hoyer wrote:
> [ .. ]
>> Please don't do that. That way we actually loose the benefit of doing as
>> much in parallel as possible. Instead please consider the patch below.
>> I've been fiddling with this for a few weeks now. It basically replaces
>> the current "wait-for-root" loop with a loop that queries the udev-queue
>> and only exits if either root is available or all udev events have been
>> processed.
>>
> D'accord.
> 
[snip]
> Ah, if it were so easy.
> 
> This approach work perfectly for any device which does synchronous scanning.
> 
> For a device doing asynchronous scan you're out of luck here as the device
> might start spitting out udev events at any time, even after the udev
> queue is empty.

Damned. I didn't think about that. Any hints how I could simulate that with kvm/qemu?

> EG usb or qla2xxx have a habit of doing so. So either you implement
> checks for each device (-type) which detects if the device is still
> scanning or you indeed just wait until the device appears.
> 
> There actually is no problem with the latter, as all the design
> goal here is to have _every_ device initialization in the background
> / asynchronously by udev.
> So in foreground we indeed just have to wait for the device node
> to appear. Even the udev queue check is pointless here; either
> we have a device node, in which case we can continue regardless
> of how many events are still in the udev queue;
> or we don't have one, in which case it quite irrelevant if
> udev has still events to process or not.

Just blindly waiting for the node to appear is dangerous. We might not
know which node to wait for or we might not have one at all (like
nfsroot for example). And in cases where the node never appears due to
lack of drivers,hardware,cmdline,... we'd never bail out without a timeout.

Suggestion: What about a solution like this?

while [ ! -d $NEWROOT/proc ] ; do
 while [ ! -d $NEWROOT/proc ] ; do
   #...current code as in my patch 
 done

 if [ ! -d $NEWROOT/proc ] ; do
    # No root around, give devices some time to do things asynchronous
    # and settle
    sleep 5
    # If the queue is still empty, bail
    udevadm settle --timeout 1 && break
 fi
done

Sleeping is not a real solution, as is just simply fiddling with timeouts.
Same goes for counting, that's why I tried to implement the udev-queue
approach after all. But I can't think of any other solution that does
not poll a devicenode.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-07-02 13:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-02 10:11 initqueue Harald Hoyer
     [not found] ` <4A4C87DF.10904-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 12:39   ` initqueue Seewer Philippe
     [not found]     ` <4A4CAA92.9000401-omB+W0Dpw2o@public.gmane.org>
2009-07-02 12:51       ` initqueue Hannes Reinecke
     [not found]         ` <4A4CAD6F.6080201-l3A5Bk7waGM@public.gmane.org>
2009-07-02 13:45           ` Seewer Philippe [this message]
2009-07-02 12:52       ` initqueue Harald Hoyer
     [not found]         ` <4A4CAD9B.10503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 13:08           ` initqueue Seewer Philippe
     [not found]             ` <4A4CB136.6000109-omB+W0Dpw2o@public.gmane.org>
2009-07-02 13:12               ` initqueue Harald Hoyer
     [not found]                 ` <4A4CB241.8080406-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 13:20                   ` initqueue Seewer Philippe
     [not found]                     ` <4A4CB434.1010001-omB+W0Dpw2o@public.gmane.org>
2009-07-02 14:10                       ` initqueue Harald Hoyer
     [not found]                         ` <4A4CBFEE.2020500-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-03  0:04                           ` initqueue Victor Lowther
     [not found]                             ` <1246579473.3339.96.camel-76q0VzFBGGr21HsLBtNmTckMGDeJXHgy@public.gmane.org>
2009-07-03  8:06                               ` initqueue Harald Hoyer
     [not found]                                 ` <4A4DBBF7.8010501-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-03  9:10                                   ` initqueue Daniel Drake

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=4A4CBA14.7010301@bfh.ch \
    --to=philippe.seewer-omb+w0dpw2o@public.gmane.org \
    --cc=harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=hare-l3A5Bk7waGM@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.