From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: initramfs: udev, hotplug, klibc and modprobe
Date: Wed, 12 Jan 2005 02:37:00 +0000 [thread overview]
Message-ID: <1105497420.6564.47.camel@localhost.localdomain> (raw)
In-Reply-To: <1105307950.9630.49.camel@juerg-p4.bitron.ch>
On Sun, 2005-01-09 at 23:25 +0100, Juerg Billeter wrote:
> As I couldn't find a documented way how to use initramfs together with
> udev, hotplug, klibc and modprobe, I've done some tests myself. I wanted
> to enable booting a fully modular kernel without initrd and custom
> hardware detection scripts on any linux-supported hardware (ide, scsi,
> usb whatever).
>
> Meanwhile it's gotten to work very well but I had to write some patches,
> scripts, little programs myself and so I thought to write down how I
> build my initramfs and I'd like to get comments from people actively
> working on udev and related technology whether my implementation makes
> sense or I've completely misunderstood something.
>
> Following my rough initramfs kernel build instructions, my files are
> marked with a footnote
>
> * Build a fully modular kernel without initramfs (2.6.10)
> * Build klibc (0.196) and copy ash and the static utils to
> initramfs
> * [1] Patch to add a stripped down, klibc-compatible
> version of module-init-tools' modprobe to the build
> * Build udev (050) with klibc and copy it to initramfs
> * [2] Patch to shorten event timeout from 10s to 3s and
> set the expected hotplug seqnum start to 5 to avoid the
> event timeout as I've never seen a hotplug event with a
> seqnum < 5, am I missing some?
The next version of udevd will have a timeout of only 2 seconds during a
startup phase. This may not be needed then.
> * [3] Patch to add udevinitd and udevinitsend. These are
> modified versions of udevd and udevsend acting as a
> "caching daemon". They save events received during early
> userspace and resend them to late userspace udevd when
> ready. This enables late userspace to process all events
> (for example to load modules not included in initramfs)
> without using coldplugging and thelike. (udevinitsend
> gets called via hotplug.d)
Nice idea. In a recent discussion, the question came up about a possible
combination of udevstart and coldplugging. It may be possible to
synthesize all the events from the information in sysfs? What do you
think about that in relation to your udevd "event queue".
Thanks,
Kay
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
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
next prev parent reply other threads:[~2005-01-12 2:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-09 21:59 initramfs: udev, hotplug, klibc and modprobe Jürg Billeter
2005-01-09 22:25 ` Juerg Billeter
2005-01-12 2:37 ` Kay Sievers [this message]
2005-01-12 5:07 ` Alexander E. Patrakov
2005-01-12 7:58 ` Jürg Billeter
2005-01-12 8:24 ` Jürg Billeter
2005-01-12 9:42 ` Harald Hoyer
2005-01-12 9:59 ` Alexander E. Patrakov
2005-01-13 1:08 ` Kay Sievers
2005-01-13 3:50 ` Alexander E. Patrakov
2005-01-13 12:55 ` Kay Sievers
2005-01-13 14:34 ` Juerg Billeter
2005-01-13 15:21 ` Kay Sievers
2005-01-13 16:16 ` Juerg Billeter
2005-01-14 9:29 ` Hannes Reinecke
2005-01-14 10:04 ` Kay Sievers
2005-01-14 10:27 ` Hannes Reinecke
2005-01-14 10:36 ` Kay Sievers
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=1105497420.6564.47.camel@localhost.localdomain \
--to=kay.sievers@vrfy.org \
--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).