Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox