From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
Kay Sievers <kay.sievers@vrfy.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [RFC][PATCH] init: Open /dev/console from rootfs
Date: Wed, 03 Mar 2010 00:35:00 -0800 [thread overview]
Message-ID: <4B8E1F34.7030604@zytor.com> (raw)
In-Reply-To: <m1sk8hn8nk.fsf@fess.ebiederm.org>
On 03/02/2010 11:53 PM, Eric W. Biederman wrote:
>
> To avoid potential problems with an empty /dev open /dev/console
> from rootfs instead of waiting to mount our root filesystem and
> mounting it there. This effectively guarantees that there will
> be a device node, and it won't be on a filesystem that we will
> ever unmount, so there are no issues with leaving /dev/console
> open and pinning the filesystem.
>
> This is actually more effective than automatically mounting
> devtmpfs on /dev because it removes removes the occasionally
> problematic assumption that /dev/console exists from the boot
> code.
>
> With this patch I was able to throw busybox on my /boot partition
> (which has no /dev directory) and boot into userspace without
> problems.
>
> The only possible negative consequence I can think of is that
> someone out there deliberately used did not use a character device
> that is major 5 minor 2 for /dev/console. Does anyone know of a
> situation in which that could make sense?
>
There probably are ... but if so, they can just re-open their new
console of choice after creating it, and/or use an initramfs which
overrides the default /dev/console.
As such, this makes a lot of sense to me.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2010-03-03 8:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 7:53 [RFC][PATCH] init: Open /dev/console from rootfs Eric W. Biederman
2010-03-03 8:35 ` H. Peter Anvin [this message]
2010-03-03 19:57 ` Al Viro
2010-03-03 20:07 ` H. Peter Anvin
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=4B8E1F34.7030604@zytor.com \
--to=hpa@zytor.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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.