Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Kenton <skenton@ou.edu>
To: buildroot@busybox.net
Subject: [Buildroot] Where is /dev/console created when using devtmpfs?
Date: Thu, 26 Mar 2015 23:14:35 -0500	[thread overview]
Message-ID: <5514D92B.4050305@ou.edu> (raw)
In-Reply-To: <CAOS_Y6SpQXSC3z2AEBH3j9wgqbbtC6=LDNb8p3fk_s0YyMe2Tw@mail.gmail.com>

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:
>> I'm currently running with devtmpfs only but am looking into using mdev
> 
> As the original author of mdev and the guy who did:
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1306.3/04204.html
> 
> I should probably poke my nose in here. :)
Thank you very much for taking the time!

> 
>> 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

> 
>         err = sys_mkdir((const char __user __force *) "/dev", 0755);
>         if (err < 0)
>                 goto out;
> 
>         err = sys_mknod((const char __user __force *) "/dev/console",
>                         S_IFCHR | S_IRUSR | S_IWUSR,
>                         new_encode_dev(MKDEV(5, 1)));
> 
> And then init/main.c does:
> 
>         /* Open the /dev/console on the rootfs, this should never fail */
>         if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
>                 printk(KERN_WARNING "Warning: unable to open an
> initial console.\n");
If I understand correctly all of which occurs on rootfs in ram and does not
touch whatever disk based filesystem may eventually get mounted on /?
> 
>         (void) sys_dup(0);
>         (void) sys_dup(0);
> 
> The devtmpfs mount happens later in the boot, and in fact I have a
> pending todo item to submit a patch to make the kernel DEVTMPFS_MOUNT
> config option actually _apply_ to initramfs. (Last I checked it would
> only mount devtmpfs on /dev in the fallback root that root= switches
> you to when you didn't have an executable /init in initramfs. I should
Apparently still the case, at least buildroot 2015.02 supplied this as /init:

#!/bin/sh
# devtmpfs does not get automounted for initramfs
/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init $*

> make it so that if it's about to exec /init out of rootfs, it does the
> above mknod /dev trick (ignore failure if it's already there) and then
> mounts devtmpfs on it (and if _that_ fails some crazy person probably
> made a file called /dev and they get to keep the pieces).
grin
> 
>> Looking at the root filesystem when it's not running shows this in /dev
>>
>> drwxrwxr-x 2 root root 4096 Mar  1 15:26 pts
>> lrwxrwxrwx 1 root root   10 Mar  1 15:26 log -> ../tmp/log
>> crw--w--w- 1 root root 5, 1 Mar 22 21:52 console
>>
>> and I see that pts and log come from the skeleton but I can't find console.
> 
> Possibly I'm answering the wrong question.
Since I'm trying to understand what's going on it's a very good answer
and I've read it multiple time while perusing the kernel code, but yes
I was originally wondering where /dev/console was created on the target
filesystem as part of the buildroot make process.

> 
> 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?

> 
> I wrote a thing about the four different types of filesystems a while back:
> 
> http://landley.livejournal.com/52326.html
Another very good read - thanks for that too

> 
>> I'm running an x86_64 system using the default vga console if that matters.
>> I'm obviously missing something but I can't find a mknod or mkdevs for it.
>>
>> Where is /dev/console created when using devtmpfs?
I was thinking in terms of the buildroot "use devtmpfs only" as opposed with mdev,
eudev, or systemd

> 
> The same place /proc/mounts is created on procfs?
> 
> The name "console" comes from drivers/tty/tty_io.c:
> 
>         consdev = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 1), NULL,
>                               "console");
OK
> 
> That sticks an entry into some kernel linked list (or possibly tree),
> which is interpreted by devtmpfs to give you a console device. It's
> also interpreted by sysfs to give you a "console" directory under
> /sys/class/tty. Both filesystem drivers are parsing the same kernel
> internal data to produce different types of output. They do so on the
> fly, when you open the relevant directory and list its contents.
Thanks again for your time and detailed explaination.

Steve

> 
>> Thanks,
>>
>> Steve
> 
> Rob
> 

  reply	other threads:[~2015-03-27  4:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 17:44 [Buildroot] Where is /dev/console created when using devtmpfs? Steve Kenton
2015-03-26 19:51 ` Rob Landley
2015-03-27  4:14   ` Steve Kenton [this message]
2015-03-27 22:14     ` Arnout Vandecappelle
2015-03-27 23:35       ` Steve Kenton
2015-03-28 20:17       ` [Buildroot] Something odd about /dev/console creation Steve Kenton
2015-03-28 23:04       ` [Buildroot] Where is /dev/console created when using devtmpfs? Rob Landley

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=5514D92B.4050305@ou.edu \
    --to=skenton@ou.edu \
    --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