[Buildroot] Where is /dev/console created when using devtmpfs?

[Rob Landley <rob@landley.net>]

On 03/27/2015 05:14 PM, Arnout Vandecappelle wrote:
> On 27/03/15 05:14, Steve Kenton wrote:
>> On 03/26/2015 02:51 PM, Rob Landley wrote:
>>> On Wed, Mar 25, 2015 at 12:44 PM, Steve Kenton <skenton@ou.edu> wrote:
> [snip]
>>>> so I spent some time looking at my device usage and for the life of me
>>>> I can't find where /dev/console gets created during the build process.
>>>
>>> The console PID 1 inherits at process launch is the /dev/console in
>>> initramfs. When you don't have initramfs, the init/noinitramfs.c code
>>> literally does:
>> Yes, this is my configuration - initramfs not linked into kernel by buildroot
>> # BR2_TARGET_ROOTFS_INITRAMFS is not set
> 
>  Just to be clear "initramfs not linked into kernel" is BR2_TARGET_ROOTFS_CPIO,
> "initramfs linked into the kernel" is BR2_TARGET_ROOTFS_INITRAMFS. But for the
> purpose of the contents of the rootfs, that doesn't make a difference.
> 
>  But so in your case, Steve, I believe you _do_ have an initramfs, i.e. you have
> selected BR2_TARGET_ROOTFS_CPIO. Otherwise /dev/console wouldn't have been
> created :-).

I note that these are buildroot symbols and I was talking about kernel
config symbols, so you may have to trace through the build process a bit
to see what the kernel .config actually winds up with and thus what
happens at boot time. But it looks like you covered that.

>>> devtmpfs is a synthetic filesystem, like /proc or /sys. You're not
>>> talking to any sort of backing store when you mount it, instead the
>>> driver is hallucinating contents for you to read and write from on the
>>> fly, and when you interact with it you talk to functions in the driver
>>> that send/receive some data they just made up to humor your request.
>> Again if I under stand correctly the contents of the on-disk  /dev on the
>> root filesystem in my case (initramfs not linked into kernel) are unused
>> and normally inaccessible because of devtmpfs mount on top?
> 
>  Indeed, its contents becomes inaccessible as soon as devtmpfs is mounted on
> top. In case of initramfs, that is when /init is executed and it is mounted
> explicitly; in case of non-initramfs, it is mounted just after / is mounted and
> before /sbin/init is executed (Rob, correct me if I'm wrong).

I mentioned I've been meaning to send a patch to make initramfs honor
the kernel's auto-mount-devtmpfs config option. Last I checked it was
only happening for root=/dev/hda style mounts, not for initramfs mounts.
(So your /init script had to mount devtmpfs, I don't think the kernel
does it for you on initramfs. But it's quite possible somebody else
fixed it in the last year or so and I didn't notice. I've been off doing
toybox and banging on sh2 nommu stuff.)

Either way, if you mount another filesystem on top of /dev, the original
contents of /dev are inaccessable until you unmount the filesystem
blocking it. This is pretty much true of the contents of any directory
you mount stuff on: the mount renders the original contents
inaccessable. (Nobody said the directory you mounted on was empty...)

(Ok, that's not _quite_ true. You can mount a filesystem on $PWD but
still access the old contents through "." until you cd out of it. A new
traversal from root wouldn't get you _back_ there, but your current
position still links to the otherwise inaccessable directory. And yes,
back in the day people hacking into 1980's unix systems would hide their
files from the sysadmin by overmounting them. Each process has "/" and
"." as two process-local symlinks indicating your current chroot inode
and your current chdir inode, all paths start from one or the other.
This leads to a fun trick for breaking out of chroots where you make a
subdirectory, call chroot(2) to point / into that subdirectory but _not_
cd into it, then chroot ../../../.. until you stop moving, then chroot /
to get access to the full tree. There's only one chroot symlink you see,
and the test for "can't cd .. past it" is an == test which won't trigger
if your cwd is currently _above_ it.)

Sorry, digression. :)

>  So with initramfs, you will have two versions of /dev/console: one real
> mknod'ed one in the initramfs itself, and a virtual one in the devtmpfs. After
> devtmpfs is mounted, the one in initramfs is no longer accessible.

Neither is "real" or "virtual". Both are device nodes with "block/char",
"major", and "minor" telling the system which driver to talk to you when
you open it.

(If you loopback mount a squashfs that contains device nodes, is that
not a "real" filesystem? How about if rhw dilw you loopback mounted it
from is on a network mount?)

Rob