From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Mon, 14 Sep 2015 15:47:42 +0200 [thread overview]
Message-ID: <55F6CFFE.3000407@lucaceresoli.net> (raw)
In-Reply-To: <20150909155427.53f9c8b5@free-electrons.com>
Dear Thomas,
Thomas Petazzoni wrote:
> Dear Luca Ceresoli,
>
> On Wed, 9 Sep 2015 14:29:36 +0200, Luca Ceresoli wrote:
>
>> The first problem is we'd have an empty /dev since the mount until the
>> execution of S10mdev. This prevents busybox init from executing all
>> lines in inittab after the mount, since they would try to open
>> /dev/null. Symptom: "can't open /dev/null: No such file or directory".
>> The fix should be simply:
>>
>> -null::sysinit:/bin/mkdir -p /dev/pts
>> -null::sysinit:/bin/mkdir -p /dev/shm
>> -null::sysinit:/bin/mount -a
>> -null::sysinit:/bin/hostname -F /etc/hostname
>> +::sysinit:/bin/mkdir -p /dev/pts
>> +::sysinit:/bin/mkdir -p /dev/shm
>> +::sysinit:/bin/mount -a
>> +::sysinit:/bin/hostname -F /etc/hostname
>>
>> Lines up to the /dev mount might be changed as well to have a more
>> uniform style, but it's not strictly needed.
>
> It actually looks better to me to *not* redirect the output of those
> commands to /dev/null. I don't know why we are doing this, but it means
> that if any of those commands wants to display something, it is
> redirected to oblivion. Not good. So it looks better to continue using
> the stdout/stderr set up by the kernel for the init process.
Aha! And removing the "null" prefix uncovered this error while booting
a static /dev system:
mkdir: can't create directory '/dev/shm': Read-only file system
Which comes from the line
::sysinit:/bin/mkdir -p /dev/shm
Yeah, time to get rid of these "null" redirects, and fix the lack of
/dev/shm in the static device table! Will do in v2.
>
> BTW, does this means that in the minimal static device table, we only
> need /dev/console? That's the only device that is opened by the kernel
> directly, I believe /dev/null was only needed for those lines.
>
>> But ehen, if any user has an S05something that uses /dev, it would
>> break. In order to reduce the risk to nearly zero, we might move
>> S10mdev to S00mdev, so it runs (most likely) as the first script.
>>
>> This would slightly change the current behaviour for all cases, and
>> start S01logging after mdev, not before. I tested it quickly and it
>> looks like it works. Can you think of any problem with moving S10mdev
>> to S00mdev?
>
> In principle, it seems better to me if the devices are all set up
> before starting anything else, so if it works, I'm all for S00mdev. The
> only question is whether mdev logs things to syslog, and if so what
> happens to those messages that are emitted before syslog is started.
At a quick code inspection it looks like mdev does not use syslog.
I'll do some testing.
--
Luca
next prev parent reply other threads:[~2015-09-14 13:47 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab Luca Ceresoli
2015-09-09 9:12 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev} Luca Ceresoli
2015-09-09 9:40 ` Arnout Vandecappelle
2015-09-09 10:53 ` Luca Ceresoli
2015-09-09 10:54 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-09 9:21 ` Arnout Vandecappelle
2015-09-09 12:29 ` Luca Ceresoli
2015-09-09 12:32 ` Arnout Vandecappelle
2015-09-09 13:54 ` Thomas Petazzoni
2015-09-14 13:47 ` Luca Ceresoli [this message]
2015-09-14 22:23 ` Arnout Vandecappelle
2015-09-15 22:35 ` Luca Ceresoli
2015-09-14 20:53 ` Peter Korsgaard
2015-09-14 21:34 ` Thomas Petazzoni
2015-09-14 21:38 ` Peter Korsgaard
2015-09-15 7:30 ` Thomas Petazzoni
2015-09-15 8:09 ` Peter Korsgaard
2015-09-15 9:41 ` Thomas Petazzoni
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 12:32 ` Peter Korsgaard
2015-09-18 16:37 ` Luca Ceresoli
2015-09-15 13:03 ` Thomas Petazzoni
2015-09-15 13:14 ` Peter Korsgaard
2015-09-15 22:34 ` Luca Ceresoli
2015-10-01 9:36 ` Luca Ceresoli
2015-10-01 10:03 ` Peter Korsgaard
2015-09-15 22:31 ` Luca Ceresoli
2015-09-16 7:32 ` Peter Korsgaard
2015-09-18 15:47 ` Luca Ceresoli
2015-09-09 9:34 ` Arnout Vandecappelle
2015-09-09 11:23 ` Thomas Petazzoni
2015-09-09 11:29 ` Thomas Petazzoni
2015-09-09 20:33 ` Arnout Vandecappelle
2015-09-14 16:07 ` Luca Ceresoli
2015-09-14 16:05 ` Luca Ceresoli
2015-09-14 19:34 ` Thomas Petazzoni
2015-09-14 20:19 ` Arnout Vandecappelle
2015-09-15 22:07 ` Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 4/6] system: strip the initial /dev for mdev-only /dev management Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" " Luca Ceresoli
2015-09-09 10:39 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 6/6] **** DO NOT COMMIT THIS **** ugly stuff to test mdev-only " Luca Ceresoli
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
2015-09-09 11:30 ` Thomas Petazzoni
2015-09-14 21:03 ` Peter Korsgaard
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=55F6CFFE.3000407@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--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