[Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)

Luca Ceresoli luca at lucaceresoli.net
Fri Sep 18 16:37:16 UTC 2015


Dear Peter,

Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout at 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


More information about the buildroot mailing list