Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Fri, 18 Sep 2015 18:37:16 +0200	[thread overview]
Message-ID: <55FC3DBC.1080800@lucaceresoli.net> (raw)
In-Reply-To: <87fv2fvp5m.fsf@dell.be.48ers.dk>

Dear Peter,

Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>
> Hi,
>
>   > On 15-09-15 14:01, Peter Korsgaard wrote:
>   >> Or alternatively, extend the S10mdev logic to detect that it need to
>   >> create a tmpfs on /dev (by looking for devtmpfs in /proc/filesystems or
>   >> detecting that /dev is RO) and have all the fixup there. That way it
>   >> atleast doesn't add any more complications to the rest of Buildroot /
>   >> users.
>
>   >  That's a great idea, because it actually simplifies the buildroot code (no
>   > longer needed to force devtmpfs in the kernel when mdev is selected).
>
>   >  To detect, it's as simple as:
>
>   > if [ "$(cut -d ' ' -f 2,3 /proc/mounts | sed -n '/^\/dev /s///p')" != devtmpfs ]
>
> Or simply 'grep -q devtmpfs /proc/filesystems'. It doesn't check if /dev
> is really a devtmpfs, but as we force DEVTMPFS_MOUNT=y (and the cpio
> init wrapper) that is probably good enough.
>
> For mdev, I think it makes more sense to check if /dev is writable, as
> that is the really what mdev requires (E.G. we could be in an initramfs
> on a <2.6.32 kernel or similar.
>

Theoretically correct, but having a dynamic /dev management on flash
storage seems a very bad idea.

In addition, i'm not sure I can write a good test to check whether it's
writable. [ -w /dev] does not consider if the filesystem is mounted
read-only. Checking if "/" has the "ro" option in /proc/mounts can be
done. But I'm not sure there are other possible configuration that make
/dev not writable for other reasons. SELinux maybe?

Mmh, overall I think the best idea is to base mdev either on devtmpfs
or on a generic tmpfs. It's more or less what Arnout's test does, except
it does not take into account the case where a tmpfs (but not devtmpfs)
is already mounted. But this should happen only if a user tweaks inittab
to do so.

-- 
Luca

  reply	other threads:[~2015-09-18 16:37 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
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 [this message]
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=55FC3DBC.1080800@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