[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aeadcb6b-3a8a-2743-d207-e068370f2302@landley.net>
Date: Thu, 11 May 2017 12:02:18 -0500
From: Rob Landley <rob@...dley.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Prarit Bhargava <prarit@...hat.com>,
Yang Shi <yang.shi@...aro.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Kees Cook <keescook@...omium.org>,
Emese Revfy <re.emese@...il.com>,
Petr Mladek <pmladek@...e.com>,
Fabian Frederick <fabf@...net.be>
Subject: Re: [PATCH] Make initramfs honor CONFIG_DEVTMPFS_MOUNT
On 05/09/2017 04:31 PM, Andrew Morton wrote:
> On Thu, 4 May 2017 16:09:06 -0500 Rob Landley <rob@...dley.net> wrote:
>
>> From: Rob Landley <rob@...dley.net>
>>
>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
>> /dev/console open after devtmpfs mount.
>
>
> Could we please see complete description of the runtime effects of this
> change? How does it affect users? How does it benefit users?
It makes the behavior consistent. If you're going to have the config
symbol anyway, why is initramfs a second class citizen?
That said, I was fixing a specific bug when I started the patch: when
you statically link in an initramfs by pointing the kernel build at a
directory (so it makes its own cpio archive from that), if you're not
running the build as root you can't create dev/console in there and
there's no obvious way to add nodes (like you can editing the
gen_initramfs_list) output.
This means there's no /dev/console when init gets launched, so PID 1's
stdin/stdout/stderr go nowhere, and until your init script can open its
own and redirect you get no output if something goes wrong, so debugging
is fiddly and there's a hole where output gets lost. Userspace can't
close that hole.
When making the patch I did a version that mounted /proc /sys and
/dev/pts too, so rdinit=/bin/sh had pretty much its full environment
without an init script just like the DEVTMPFS_MOUNT option's help text
implied... but that seemed unlikely to be accepted. The console gap is a
problem userspace can't fix, the rest userspace can, so I did the
minimal thing.
> The DEVTMPFS_MOUNT Kconfig help (drivers/base/Kconfig) says:
>
> This option does not affect initramfs based booting, here
> the devtmpfs filesystem always needs to be mounted manually
> after the rootfs is mounted.
>
> which seems to no longer be correct?
Ah, sorry. I rewrote the help text and didn't include that file in the
diff. And rechecking I see the override part wasn't implemented by my
patch, I'll send a new one.
Rob
Powered by blists - more mailing lists