From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] devtmpfs and initramfs
Date: Wed, 20 Jul 2011 13:00:38 +0200 [thread overview]
Message-ID: <201107201300.39616.arnout@mind.be> (raw)
In-Reply-To: <874o2h2pif.fsf@macbook.be.48ers.dk>
On Wednesday 20 July 2011 12:52:08, Peter Korsgaard wrote:
> >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> Hi,
>
> >> > #!/bin/sh
> >> > # devtmpfs does not get automounted for initramfs'es
> >> > /bin/mount -t devtmpfs devtmpfs /dev
> >> > exec /sbin/init $*
> >> >
> >> > Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
> >>
> >> Sorry, but this solution smells just like my socks. I think wk can find
> >> a better one :)
>
> Arnout> Yeah, I also would prefer not to proliferate the number of
> Arnout> ways that the init process is influenced...
>
> I don't see what there is to dislike. With this, the non-standard
> behaviour of initramfs'es is nicely self contained within the initramfs
> support code, and nothing else needs to know about it. There's nothing
> to tweak, and it just works out of the box (tm), no matter what init
> implementation or custom inittab is used.
But next thing you know, some other piece of Makefile also wants to do
something with /init...
Since it potentially interacts with other parts of the build, I would argue
that it _should_not_ be self-contained.
That said, I'm not too enthousiastic about the rc.S solution either, since it
may also interact badly with alternative init procedures.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
next prev parent reply other threads:[~2011-07-20 11:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 10:22 [Buildroot] devtmpfs and initramfs Arnout Vandecappelle
2011-07-19 10:33 ` Peter Korsgaard
2011-07-19 11:23 ` Arnout Vandecappelle
2011-07-20 7:44 ` Diego Iastrubni
2011-07-20 8:01 ` Peter Korsgaard
2011-07-20 8:03 ` Arnout Vandecappelle
2011-07-20 8:15 ` Peter Korsgaard
2011-07-20 8:48 ` Diego Iastrubni
2011-07-20 8:57 ` Arnout Vandecappelle
2011-07-20 10:52 ` Peter Korsgaard
2011-07-20 11:00 ` Arnout Vandecappelle [this message]
2011-07-20 17:41 ` Peter Korsgaard
2011-07-20 15:10 ` Arnout Vandecappelle
2011-07-20 15:29 ` Peter Korsgaard
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=201107201300.39616.arnout@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/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.