summaryrefslogtreecommitdiff
path: root/fs/udf
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2010-03-02 23:53:19 -0800
committerAl Viro <viro@zeniv.linux.org.uk>2010-03-03 14:56:07 -0500
commit2bd3a997befc226ab4b504f05c5cbba305f3e0e6 (patch)
treeb510653236a8db16d6eaaf5b8b8c47000ee1b754 /fs/udf
parent2329e392accdb1b277927e8d9cbf568ba3f3856d (diff)
downloadlinux-3.10-2bd3a997befc226ab4b504f05c5cbba305f3e0e6.tar.gz
linux-3.10-2bd3a997befc226ab4b504f05c5cbba305f3e0e6.tar.bz2
linux-3.10-2bd3a997befc226ab4b504f05c5cbba305f3e0e6.zip
init: Open /dev/console from rootfs
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? Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/udf')
0 files changed, 0 insertions, 0 deletions