All the mail mirrored from 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: Mon, 14 Sep 2015 18:05:52 +0200	[thread overview]
Message-ID: <55F6F060.2060901@lucaceresoli.net> (raw)
In-Reply-To: <20150909132929.5c01433e@free-electrons.com>

Dear Thomas,

Thomas Petazzoni wrote:
> Luca,
>
> On Tue,  8 Sep 2015 23:28:51 +0200, Luca Ceresoli wrote:
>> There are a few reasons for an embedded Linux system not to use devtmpfs,
>> but still want to have dynamic /dev management. The most notable is to use
>> a kernel < 2.6.32, which have no devtmpfs support.
>>
>> For such corner cases, we introduce the ability to use busybox mdev for
>> /dev management even without devtmpfs.
>>
>> First, we need the BR2_ROOTFS_STATIC_DEVICE_TABLE just like the static
>> /dev management, in order to have the very basic devices such as /dev/null
>> and /dev/console until mdev is enabled.
>
> As said in another e-mail, this is not really true: we just need a very
> simple, two devices long, hard-coded device table. There is no need to
> allow the user to customize it. It would in fact be potentially
> misleading because the user who would add more devices in this static
> device table would not see them on the target: they would be
> "overridden" by the tmpfs mounted in /dev.

Yup, I did that in patch 4.

But now I removed that patch, and replaced with a different
implementation based on Arnout's suggestion of using BUSYBOX_DEVICES.

>
>> But doing this in S10mdev, which already does something similar, would be a
>> bit complex because when S10mdev runs /dev/shm and /dev/pts are already
>> mounted. We might unmount, recreate and mount them again, but devices in
>> them might be already in use. Or we could leave the "old" alone, and mount
>> them again in the newly created /dev. Both solutions are dirty and
>> potentially problematic.
>>
>> Instead we hook in inittab (both busybox and sysvinit) and do the same
>> incantations there, right after mounting /sys (needed for mdev) but before
>> any other actions on /dev, such as creating and mounting /dev/shm and
>> /dev/pts. We also skip installing S10mdev: it would do the same things
>> twice. In order to keep the inittab files concise and maintainable, this
>> taks is delegated to a helper script, /sbin/activate-mdev.
>
> taks -> task

Sure.

>
> One thing I dislike a bit is that there is quite a bit overlap between
> S10mdev and activate-mdev. As Arnout suggested, can you just mount a
> tmpfs in /dev in the inittab in the "mdev without devtmpfs" case, and
> then keep the normal S10mdev script?

v2 will do things this way.

>
>> diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
>> index 6e302f4..f95ff52 100644
>> --- a/package/busybox/busybox.mk
>> +++ b/package/busybox/busybox.mk
>> @@ -55,11 +55,18 @@ define BUSYBOX_PERMISSIONS
>>   endef
>>
>>   # If mdev will be used for device creation enable it and copy S10mdev to /etc/init.d
>> +ifeq ($(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV)$(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY),y)
>>   ifeq ($(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV),y)
>>   define BUSYBOX_INSTALL_MDEV_SCRIPT
>>   	$(INSTALL) -D -m 0755 package/busybox/S10mdev \
>>   		$(TARGET_DIR)/etc/init.d/S10mdev
>>   endef
>> +else
>> +define BUSYBOX_INSTALL_MDEV_SCRIPT
>> +	$(INSTALL) -D -m 0755 package/busybox/activate-mdev \
>> +		$(TARGET_DIR)/sbin/activate-mdev
>> +endef
>> +endif
>
> Any reason to enclose the internal condition inside a bigger condition?
>
> (Of course, this becomes moot if we can use S10mdev in both cases)

Indeed, I removed entirely that script in the next iteration.

>
>> diff --git a/package/skeleton/skeleton.mk b/package/skeleton/skeleton.mk
>> index 48e7085..975e2a5 100644
>> --- a/package/skeleton/skeleton.mk
>> +++ b/package/skeleton/skeleton.mk
>> @@ -141,6 +141,7 @@ TARGET_FINALIZE_HOOKS += SKELETON_SYSTEM_GETTY
>>   endif
>>
>>   ifeq ($(BR2_INIT_BUSYBOX)$(BR2_INIT_SYSV),y)
>> +
>
> Not really related to the change.

I just wanted to highlight the two main blocks inside that ifeq:
[un]commenting read-write mount and [un]commenting the mdev line. The
code there is lengthy and not very readable IMHO. But ok, removed that.

>> diff --git a/system/Config.in b/system/Config.in
>> index 5bf5048..a10de1e 100644
>> --- a/system/Config.in
>> +++ b/system/Config.in
>> @@ -106,6 +106,10 @@ choice
>>   config BR2_ROOTFS_DEVICE_CREATION_STATIC
>>   	bool "Static using device table"
>>
>> +config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY
>> +	bool "Dynamic using mdev only"
>> +	select BR2_PACKAGE_BUSYBOX
>> +
>>   config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
>>   	bool "Dynamic using devtmpfs only"
>>
>> @@ -144,7 +148,7 @@ config BR2_ROOTFS_DEVICE_TABLE
>>   config BR2_ROOTFS_STATIC_DEVICE_TABLE
>>   	string "Path to the device tables"
>>   	default "system/device_table_dev.txt"
>> -	depends on BR2_ROOTFS_DEVICE_CREATION_STATIC
>> +	depends on BR2_ROOTFS_DEVICE_CREATION_STATIC || BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY
>
> As suggested above, we probably don't want to show this option in the
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY case.

That's not present in v2.

-- 
Luca

  parent reply	other threads:[~2015-09-14 16:05 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
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 [this message]
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=55F6F060.2060901@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.