From: Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>
To: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: initqueue
Date: Thu, 2 Jul 2009 15:20:52 +0200 [thread overview]
Message-ID: <4A4CB434.1010001@bfh.ch> (raw)
In-Reply-To: <4A4CB241.8080406-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Harald Hoyer wrote:
> On 07/02/2009 03:08 PM, Seewer Philippe wrote:
>> Harald Hoyer wrote:
>>> On 07/02/2009 02:39 PM, Seewer Philippe wrote:
>>>> Harald Hoyer wrote:
>>>>> To move all "big" jobs out of the udev event handling, I introduce the
>>>>> "initqueue". This prevents the job from being killed by udev timeouts.
>>>>>
>>>>> See
>>>>> http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> for the patch.
>>>>>
>>>>> Basically inside a udev event, you don't do
>>>>>
>>>>> RUN+="/sbin/ifup $env{INTERFACE}"
>>>>>
>>>>> you now queue this in the initqueue with:
>>>>>
>>>>> RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"
>>>>>
>>>>> Inside init all jobs are worked on in serial order by the
>>>>> do_initqueue() function.
>>>>>
>>>>> Now we have no more side effects due to the parallel nature of udev
>>>>> and still be fast, in case udev supports "udevadm settle
>>>>> --exit-if-exists="
>>>>
>>>> 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.
>>>>
>>>> It works, except if a udev event takes longer than the default 180s
>>>> as is
>>>> the case with an unpatches cryptsetup and/or if we do user-interaction
>>>> from within udev which we shouldn't do anyway.
>>>>
>>>> Thank you,
>>>> Philippe
>>>>
>>>
>>> Well, you could remove the initqueue for ifup events, but I would like
>>> to keep it at least for cryptsetup.
>>
>> Why not just put cryptsetup back into mountscripts as I've suggested
>> before?
>>
>
> Because so much more can be inside the crypto partition, which might
> need further processing.
That is correct. But if it's in mountscripts, it would fire more
udev-events which are caught again by udevadm settle. I don't see
a problem there.
--
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
next prev parent reply other threads:[~2009-07-02 13:20 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 ` initqueue Seewer Philippe
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 ` Seewer Philippe [this message]
[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=4A4CB434.1010001@bfh.ch \
--to=philippe.seewer-omb+w0dpw2o@public.gmane.org \
--cc=harald-H+wXaHxf7aLQT0dZR+AlfA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox