* [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs)
@ 2015-09-08 21:28 Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab Luca Ceresoli
` (7 more replies)
0 siblings, 8 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
Hi,
this patchset adds a new /dev management mechanism, using mdev for
dynamic device creation but without relying on devtmpfs.
The main motivation is the need of dynamic /dev management and/or firmware
loading assisted by mdev on targets that are bound to kernels < 2.6.32,
and thus cannot use devtmpfs.
The topic has been discussed back in July when I proposed a totally
unacceptable implementation. In the discussion that followed I made a
proposal [0], whose general principle was positively received by Thomas.
The proposal is to augment the /dev management choice this way:
( ) Static using device table
( ) Static using device table + mdev <- New option
(X) Dynamic using devtmpfs only
( ) Dynamic using {devtmpfs +} mdev {} = new wording only
( ) Dynamic using {devtmpfs +} eudev {} = new wording only
Of course we still have a static table to make the system boot until mdev
is activated.
In order to activate mdev I first tried to hook in S10mdev to make a boot
process that is similar to the current "devtmpfs + mdev" case. But that
didn't work well, because when S10mdev runs /dev/shm and /dev/pts are
already mounted. This raises issues explained in detail in the commit log
for patch 3.
Instead the approached that worked best is to activate mdev as early as
possible, i.e. in inittab. This makes the system boot (of course) like the
static case for the few very initial moments of userspace life: launching
init and mounting /proc and /sys; yes, we now mount /sys in inittab, it's
needed by mdev. Then mdev is enabled, and things look very much like any
other dynamic method since then.
In the end I think the modifications to implement this feature are
relatively few, and it all works well. I tested it with 10 qemu configs,
testing every /dev management method with both busybox and sysvinit init.
Patch 6 shows my ugly testing scripts.
So it is quite stable. It is called an RFC because the change touches a few
important lines and because this addition was not considered a good idea by
Peter, according to Thomas' memory [1].
I even wondered whether this new kind of /dev management should replace
the "devtmpfs + mdev" at some point, since it does not seem to provide
any drawback. Unless I'm missing something, which is definitely possible...
There is one rough edge that I'd like to have comments about: variable
naming. The new method implemented by this patchset is dynamic and uses
mdev, so it should ba named BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV and
described in kconfig as "dynamic using mdev". But hey, that name and
description are already used for the current "devtmpfs + mdev" method! So
we might want to rename all variables to encompass the new use case in a
clean way. Thid would also imply lagacy management etc.
For the time being I didn't enter the jungle of variable naming and just
expanded the description for the current mdev and eudev cases to clarify
they also use devtmpfs. This is done in patch 2. Then I called the newly
introduced method BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY and
described it "Dynamic using mdev only", to make sure it is well
distinguishable@least during teh oatch review process. If the overall
work is considered good, I'll take care of the renaming in a future
patchset.
Here are a few figures about the storage space needed for the various
configurations. All are compared to the "devtmpfs + mdev" reference method.
Not a big surprise, the differences are all quite negligible, being all
below 1%.
devtmpfs+mdev: zImage 2.1 MB, rootfs.ext2 6.8 MB
-------------------------------------------------------
devtmpfs-only delta: zImage equal, rootfs.ext2 -9 kB
mdev-only delta: zImage -1.6 kB, rootfs.ext2 equal
static delta: zImage -1.6 kB, rootfs.ext2 +28 kB
Luca
[0] http://lists.busybox.net/pipermail/buildroot/2015-July/133695.html
[1] http://lists.busybox.net/pipermail/buildroot/2015-July/133701.html
Luca Ceresoli (6):
Move mounting /sys from fstab to inittab
system: clarify /dev management using devtmpfs + {mdev,eudev}
system: add mdev-only /dev management (without devtmpfs)
system: strip the initial /dev for mdev-only /dev management
docs/manual: document "Dynamic using mdev only" /dev management
**** DO NOT COMMIT THIS **** ugly stuff to test mdev-only /dev
management
.gitignore | 1 +
configs/test_bb_dyn_devtmpfs_defconfig | 12 ++++++++++++
configs/test_bb_dyn_eudev_defconfig | 13 +++++++++++++
configs/test_bb_dyn_mdev_defconfig | 13 +++++++++++++
configs/test_bb_mdev_only_defconfig | 13 +++++++++++++
configs/test_bb_static_defconfig | 13 +++++++++++++
configs/test_sv_dyn_devtmpfs_defconfig | 13 +++++++++++++
configs/test_sv_dyn_eudev_defconfig | 14 ++++++++++++++
configs/test_sv_dyn_mdev_defconfig | 14 ++++++++++++++
configs/test_sv_mdev_only_defconfig | 14 ++++++++++++++
configs/test_sv_static_defconfig | 14 ++++++++++++++
docs/manual/configure.txt | 18 +++++++++++++++---
linux/linux.mk | 2 +-
package/busybox/activate-mdev | 5 +++++
package/busybox/busybox.mk | 7 +++++++
package/busybox/inittab | 2 ++
package/skeleton/skeleton.mk | 15 +++++++++++++++
package/sysvinit/inittab | 14 ++++++++------
run | 12 ++++++++++++
system/Config.in | 11 ++++++++---
system/device_table_dev_mdev_only.txt | 10 ++++++++++
system/skeleton/etc/fstab | 1 -
test-all | 34 ++++++++++++++++++++++++++++++++++
23 files changed, 251 insertions(+), 14 deletions(-)
create mode 100644 configs/test_bb_dyn_devtmpfs_defconfig
create mode 100644 configs/test_bb_dyn_eudev_defconfig
create mode 100644 configs/test_bb_dyn_mdev_defconfig
create mode 100644 configs/test_bb_mdev_only_defconfig
create mode 100644 configs/test_bb_static_defconfig
create mode 100644 configs/test_sv_dyn_devtmpfs_defconfig
create mode 100644 configs/test_sv_dyn_eudev_defconfig
create mode 100644 configs/test_sv_dyn_mdev_defconfig
create mode 100644 configs/test_sv_mdev_only_defconfig
create mode 100644 configs/test_sv_static_defconfig
create mode 100755 package/busybox/activate-mdev
create mode 100755 run
create mode 100644 system/device_table_dev_mdev_only.txt
create mode 100755 test-all
--
1.9.1
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
@ 2015-09-08 21:28 ` 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
` (6 subsequent siblings)
7 siblings, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
We are going to launch mdev from inittab, to have dynamic /dev without
devtmpfs. However, mdev needs /sys to detect devices.
So, mount /sys before the place where mdev will be activated.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
package/busybox/inittab | 1 +
package/sysvinit/inittab | 13 +++++++------
system/skeleton/etc/fstab | 1 -
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/package/busybox/inittab b/package/busybox/inittab
index b1892c1..6703fc5 100644
--- a/package/busybox/inittab
+++ b/package/busybox/inittab
@@ -15,6 +15,7 @@
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
+null::sysinit:/bin/mount -t sysfs sysfs /sys
null::sysinit:/bin/mount -o remount,rw /
null::sysinit:/bin/mkdir -p /dev/pts
null::sysinit:/bin/mkdir -p /dev/shm
diff --git a/package/sysvinit/inittab b/package/sysvinit/inittab
index fc0c9b5..6ebf6fa 100644
--- a/package/sysvinit/inittab
+++ b/package/sysvinit/inittab
@@ -5,12 +5,13 @@
id:3:initdefault:
si0::sysinit:/bin/mount -t proc proc /proc
-si1::sysinit:/bin/mount -o remount,rw /
-si2::sysinit:/bin/mkdir -p /dev/pts
-si3::sysinit:/bin/mkdir -p /dev/shm
-si4::sysinit:/bin/mount -a
-si5::sysinit:/bin/hostname -F /etc/hostname
-si6::sysinit:/etc/init.d/rcS
+si1::sysinit:/bin/mount -t sysfs sysfs /sys
+si2::sysinit:/bin/mount -o remount,rw /
+si3::sysinit:/bin/mkdir -p /dev/pts
+si4::sysinit:/bin/mkdir -p /dev/shm
+si5::sysinit:/bin/mount -a
+si6::sysinit:/bin/hostname -F /etc/hostname
+si7::sysinit:/etc/init.d/rcS
# S0:1:respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
diff --git a/system/skeleton/etc/fstab b/system/skeleton/etc/fstab
index 2b418a0..489f256 100644
--- a/system/skeleton/etc/fstab
+++ b/system/skeleton/etc/fstab
@@ -5,4 +5,3 @@ devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs mode=0777 0 0
tmpfs /tmp tmpfs mode=1777 0 0
tmpfs /run tmpfs mode=0755,nosuid,nodev 0 0
-sysfs /sys sysfs defaults 0 0
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev}
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-08 21:28 ` Luca Ceresoli
2015-09-09 9:40 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (5 subsequent siblings)
7 siblings, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
We're going to introduce /dev management with mdev only (no devtmpfs),
which will be called "Dynamic using mdev only".
In preparation to that addition, clarify the current /dev managements
systems which use devtmpfs with an additional tool. Otherwise
"Dynamic using mdev" and "Dynamic using mdev only" wight look quite
undistinguishable to mortals...
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
docs/manual/configure.txt | 7 ++++---
system/Config.in | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index dd34eef..997be2b 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -295,7 +295,7 @@ different solutions to handle the +/dev+ directory :
responsibility to enable those two options (if you fail to do so,
your Buildroot system will not boot).
- * The third solution is *Dynamic using mdev*. This method also relies
+ * The third solution is *Dynamic using devtmpfs + mdev*. This method also relies
on the _devtmpfs_ virtual filesystem detailed above (so the
requirement to have +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+
enabled in the kernel configuration still apply), but adds the
@@ -314,7 +314,7 @@ different solutions to handle the +/dev+ directory :
about +mdev+ and the syntax of its configuration file, see
http://git.busybox.net/busybox/tree/docs/mdev.txt.
- * The fourth solution is *Dynamic using eudev*. This method also
+ * The fourth solution is *Dynamic using devtmpfs + eudev*. This method also
relies on the _devtmpfs_ virtual filesystem detailed above, but
adds the +eudev+ userspace daemon on top of it. +eudev+ is a daemon
that runs in the background, and gets called by the kernel when a
@@ -327,7 +327,8 @@ different solutions to handle the +/dev+ directory :
The Buildroot developers recommendation is to start with the *Dynamic
using devtmpfs only* solution, until you have the need for userspace
to be notified when devices are added/removed, or if firmwares are
-needed, in which case *Dynamic using mdev* is usually a good solution.
+needed, in which case *Dynamic using devtmpfs + mdev* is usually a
+good solution.
Note that if +systemd+ is chosen as init system, /dev management will
be performed by the +udev+ program provided by +systemd+.
diff --git a/system/Config.in b/system/Config.in
index fad829d..5bf5048 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -110,11 +110,11 @@ config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
bool "Dynamic using devtmpfs only"
config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV
- bool "Dynamic using mdev"
+ bool "Dynamic using devtmpfs + mdev"
select BR2_PACKAGE_BUSYBOX
config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV
- bool "Dynamic using eudev"
+ bool "Dynamic using devtmpfs + eudev"
depends on BR2_USE_WCHAR
depends on !BR2_STATIC_LIBS
depends on BR2_USE_MMU # eudev
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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-08 21:28 ` [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev} Luca Ceresoli
@ 2015-09-08 21:28 ` Luca Ceresoli
2015-09-09 9:21 ` Arnout Vandecappelle
` (2 more replies)
2015-09-08 21:28 ` [Buildroot] [RFC 4/6] system: strip the initial /dev for mdev-only /dev management Luca Ceresoli
` (4 subsequent siblings)
7 siblings, 3 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
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.
Then we mount a tmpfs on /dev and enable mdev using the incantations:
/bin/mount -t tmpfs mdev /dev
echo /sbin/mdev >/proc/sys/kernel/hotplug
/sbin/mdev -s
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.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
linux/linux.mk | 2 +-
package/busybox/activate-mdev | 5 +++++
package/busybox/busybox.mk | 7 +++++++
package/busybox/inittab | 1 +
package/skeleton/skeleton.mk | 15 +++++++++++++++
package/sysvinit/inittab | 13 +++++++------
system/Config.in | 6 +++++-
7 files changed, 41 insertions(+), 8 deletions(-)
create mode 100755 package/busybox/activate-mdev
diff --git a/linux/linux.mk b/linux/linux.mk
index bbcc54b..bbac1e6 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -190,7 +190,7 @@ define LINUX_KCONFIG_FIXUP_CMDS
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,"$${BR_BINARIES_DIR}/rootfs.cpio",$(@D)/.config)
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_UID,0,$(@D)/.config)
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_GID,0,$(@D)/.config))
- $(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),,
+ $(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC)$(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY),,
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config))
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV),
diff --git a/package/busybox/activate-mdev b/package/busybox/activate-mdev
new file mode 100755
index 0000000..db2a53d
--- /dev/null
+++ b/package/busybox/activate-mdev
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+/bin/mount -t tmpfs mdev /dev
+echo /sbin/mdev >/proc/sys/kernel/hotplug
+/sbin/mdev -s
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
define BUSYBOX_INSTALL_MDEV_CONF
$(INSTALL) -D -m 0644 package/busybox/mdev.conf \
$(TARGET_DIR)/etc/mdev.conf
diff --git a/package/busybox/inittab b/package/busybox/inittab
index 6703fc5..eaba42f 100644
--- a/package/busybox/inittab
+++ b/package/busybox/inittab
@@ -16,6 +16,7 @@
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -t sysfs sysfs /sys
+#null::sysinit:/sbin/activate-mdev
null::sysinit:/bin/mount -o remount,rw /
null::sysinit:/bin/mkdir -p /dev/pts
null::sysinit:/bin/mkdir -p /dev/shm
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)
+
ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y)
# Find commented line, if any, and remove leading '#'s
define SKELETON_SYSTEM_REMOUNT_RW
@@ -153,6 +154,20 @@ define SKELETON_SYSTEM_REMOUNT_RW
endef
endif
TARGET_FINALIZE_HOOKS += SKELETON_SYSTEM_REMOUNT_RW
+
+ifeq ($(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY),y)
+# Find commented line, if any, and remove leading '#'s
+define SKELETON_SYSTEM_EARLY_MDEV
+ $(SED) '/^#.*sbin\/activate-mdev$$/s~^#\+~~' $(TARGET_DIR)/etc/inittab
+endef
+else
+# Find uncommented line, if any, and add a leading '#'
+define SKELETON_SYSTEM_EARLY_MDEV
+ $(SED) '/^[^#].*sbin\/activate-mdev$$/s~^~#~' $(TARGET_DIR)/etc/inittab
+endef
+endif
+TARGET_FINALIZE_HOOKS += SKELETON_SYSTEM_EARLY_MDEV
+
endif # BR2_INIT_BUSYBOX || BR2_INIT_SYSV
endif # BR2_ROOTFS_SKELETON_DEFAULT
diff --git a/package/sysvinit/inittab b/package/sysvinit/inittab
index 6ebf6fa..5abca7f 100644
--- a/package/sysvinit/inittab
+++ b/package/sysvinit/inittab
@@ -6,12 +6,13 @@ id:3:initdefault:
si0::sysinit:/bin/mount -t proc proc /proc
si1::sysinit:/bin/mount -t sysfs sysfs /sys
-si2::sysinit:/bin/mount -o remount,rw /
-si3::sysinit:/bin/mkdir -p /dev/pts
-si4::sysinit:/bin/mkdir -p /dev/shm
-si5::sysinit:/bin/mount -a
-si6::sysinit:/bin/hostname -F /etc/hostname
-si7::sysinit:/etc/init.d/rcS
+si2::sysinit:/sbin/activate-mdev
+si3::sysinit:/bin/mount -o remount,rw /
+si4::sysinit:/bin/mkdir -p /dev/pts
+si5::sysinit:/bin/mkdir -p /dev/shm
+si6::sysinit:/bin/mount -a
+si7::sysinit:/bin/hostname -F /etc/hostname
+si8::sysinit:/etc/init.d/rcS
# S0:1:respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
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
help
Specify a space-separated list of device table locations,
that will be passed to the makedevs utility to create all
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 4/6] system: strip the initial /dev for mdev-only /dev management
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (2 preceding siblings ...)
2015-09-08 21:28 ` [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs) Luca Ceresoli
@ 2015-09-08 21:28 ` Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" " Luca Ceresoli
` (3 subsequent siblings)
7 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
When using mdev-only /dev management a static device table is needed before
mdev is activated. This is used only for a very short time and then
replaced by the dymanic table managen by mdev, so it should be very
minimalistic.
But the current default, system/device_table_dev.txt, contains way too many
devices that are useless in this contex.
Replace it with a very minimal table.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
system/Config.in | 1 +
system/device_table_dev_mdev_only.txt | 10 ++++++++++
2 files changed, 11 insertions(+)
create mode 100644 system/device_table_dev_mdev_only.txt
diff --git a/system/Config.in b/system/Config.in
index a10de1e..48558b1 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -147,6 +147,7 @@ config BR2_ROOTFS_DEVICE_TABLE
config BR2_ROOTFS_STATIC_DEVICE_TABLE
string "Path to the device tables"
+ default "system/device_table_dev_mdev_only.txt" if BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY
default "system/device_table_dev.txt"
depends on BR2_ROOTFS_DEVICE_CREATION_STATIC || BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY
help
diff --git a/system/device_table_dev_mdev_only.txt b/system/device_table_dev_mdev_only.txt
new file mode 100644
index 0000000..477aaea
--- /dev/null
+++ b/system/device_table_dev_mdev_only.txt
@@ -0,0 +1,10 @@
+# See package/makedevs/README for details
+#
+# This device table is used only to create device files when a static
+# device configuration is used (entries in /dev are static).
+#
+# <name> <type> <mode> <uid> <gid> <major> <minor> <start> <inc> <count>
+
+# Normal system devices
+/dev/null c 666 0 0 1 3 0 0 -
+/dev/console c 666 0 0 5 1 - - -
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" /dev management
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (3 preceding siblings ...)
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 ` 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
` (2 subsequent siblings)
7 siblings, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
docs/manual/configure.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index 997be2b..ea78d96 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -324,6 +324,17 @@ different solutions to handle the +/dev+ directory :
daemon used in most desktop Linux distributions, which is now part
of Systemd. For more details, see http://en.wikipedia.org/wiki/Udev.
+ * *Dynamic using mdev only* uses +mdev+ and allows to use all the
+ features of +mdev+, including dynamic device creation and firmware
+ handling, but does not use _devtmpfs_.
+ If you have to use a kernel older than 2.6.32 this is the only
+ option to have dynamic /dev management, although it can be used
+ with more recent versions of the kernel as well.
+ If you build your Linux kernel outside of Buildroot, you should
+ disable +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+ in your kernel
+ configuration. When Buildroot is in charge of building the Linux
+ kernel, it disables them automatically.
+
The Buildroot developers recommendation is to start with the *Dynamic
using devtmpfs only* solution, until you have the need for userspace
to be notified when devices are added/removed, or if firmwares are
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 6/6] **** DO NOT COMMIT THIS **** ugly stuff to test mdev-only /dev management
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (4 preceding siblings ...)
2015-09-08 21:28 ` [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" " Luca Ceresoli
@ 2015-09-08 21:28 ` Luca Ceresoli
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
2015-09-14 21:03 ` Peter Korsgaard
7 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-08 21:28 UTC (permalink / raw)
To: buildroot
2 init systems (busybox, sysvinit) x 5 /dev management = 10 defconfigs.
All based on qemu_arm_versatile_defconfig + external toolchain +
read-only rootfs (to test in the worst possible conditions).
To run-test one:
./run <your_output_dir> (default "output/")
To build- and run-test all:
./test-all build
./test-all run
Not-signed-off-by: anybody
---
.gitignore | 1 +
configs/test_bb_dyn_devtmpfs_defconfig | 12 ++++++++++++
configs/test_bb_dyn_eudev_defconfig | 13 +++++++++++++
configs/test_bb_dyn_mdev_defconfig | 13 +++++++++++++
configs/test_bb_mdev_only_defconfig | 13 +++++++++++++
configs/test_bb_static_defconfig | 13 +++++++++++++
configs/test_sv_dyn_devtmpfs_defconfig | 13 +++++++++++++
configs/test_sv_dyn_eudev_defconfig | 14 ++++++++++++++
configs/test_sv_dyn_mdev_defconfig | 14 ++++++++++++++
configs/test_sv_mdev_only_defconfig | 14 ++++++++++++++
configs/test_sv_static_defconfig | 14 ++++++++++++++
run | 12 ++++++++++++
test-all | 34 ++++++++++++++++++++++++++++++++++
13 files changed, 180 insertions(+)
create mode 100644 configs/test_bb_dyn_devtmpfs_defconfig
create mode 100644 configs/test_bb_dyn_eudev_defconfig
create mode 100644 configs/test_bb_dyn_mdev_defconfig
create mode 100644 configs/test_bb_mdev_only_defconfig
create mode 100644 configs/test_bb_static_defconfig
create mode 100644 configs/test_sv_dyn_devtmpfs_defconfig
create mode 100644 configs/test_sv_dyn_eudev_defconfig
create mode 100644 configs/test_sv_dyn_mdev_defconfig
create mode 100644 configs/test_sv_mdev_only_defconfig
create mode 100644 configs/test_sv_static_defconfig
create mode 100755 run
create mode 100755 test-all
diff --git a/.gitignore b/.gitignore
index bb02d9f..9f335cc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@
*.rej
*~
*.pyc
+bld
diff --git a/configs/test_bb_dyn_devtmpfs_defconfig b/configs/test_bb_dyn_devtmpfs_defconfig
new file mode 100644
index 0000000..fdddb63
--- /dev/null
+++ b/configs/test_bb_dyn_devtmpfs_defconfig
@@ -0,0 +1,12 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_bb_dyn_eudev_defconfig b/configs/test_bb_dyn_eudev_defconfig
new file mode 100644
index 0000000..bb07e99
--- /dev/null
+++ b/configs/test_bb_dyn_eudev_defconfig
@@ -0,0 +1,13 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_bb_dyn_mdev_defconfig b/configs/test_bb_dyn_mdev_defconfig
new file mode 100644
index 0000000..5f6a715
--- /dev/null
+++ b/configs/test_bb_dyn_mdev_defconfig
@@ -0,0 +1,13 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_bb_mdev_only_defconfig b/configs/test_bb_mdev_only_defconfig
new file mode 100644
index 0000000..e2e7ec8
--- /dev/null
+++ b/configs/test_bb_mdev_only_defconfig
@@ -0,0 +1,13 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_bb_static_defconfig b/configs/test_bb_static_defconfig
new file mode 100644
index 0000000..9e79fca
--- /dev/null
+++ b/configs/test_bb_static_defconfig
@@ -0,0 +1,13 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_ROOTFS_DEVICE_CREATION_STATIC=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_sv_dyn_devtmpfs_defconfig b/configs/test_sv_dyn_devtmpfs_defconfig
new file mode 100644
index 0000000..b0d758b
--- /dev/null
+++ b/configs/test_sv_dyn_devtmpfs_defconfig
@@ -0,0 +1,13 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_INIT_SYSV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_sv_dyn_eudev_defconfig b/configs/test_sv_dyn_eudev_defconfig
new file mode 100644
index 0000000..a2142be
--- /dev/null
+++ b/configs/test_sv_dyn_eudev_defconfig
@@ -0,0 +1,14 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_INIT_SYSV=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_sv_dyn_mdev_defconfig b/configs/test_sv_dyn_mdev_defconfig
new file mode 100644
index 0000000..02d6ca3
--- /dev/null
+++ b/configs/test_sv_dyn_mdev_defconfig
@@ -0,0 +1,14 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_INIT_SYSV=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_sv_mdev_only_defconfig b/configs/test_sv_mdev_only_defconfig
new file mode 100644
index 0000000..7e7489f
--- /dev/null
+++ b/configs/test_sv_mdev_only_defconfig
@@ -0,0 +1,14 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_INIT_SYSV=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/configs/test_sv_static_defconfig b/configs/test_sv_static_defconfig
new file mode 100644
index 0000000..2177aa0
--- /dev/null
+++ b/configs/test_sv_static_defconfig
@@ -0,0 +1,14 @@
+BR2_arm=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_INIT_SYSV=y
+BR2_ROOTFS_DEVICE_CREATION_STATIC=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/arm-versatile/linux-4.2.config"
+BR2_LINUX_KERNEL_ZIMAGE=y
+BR2_TARGET_ROOTFS_EXT2=y
+# BR2_TARGET_ROOTFS_TAR is not set
diff --git a/run b/run
new file mode 100755
index 0000000..56618a4
--- /dev/null
+++ b/run
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+set -e
+set -u
+
+OUTDIR=$([ -z "$1" ] && echo output || echo $1)
+
+qemu-system-arm -M versatilepb \
+ -kernel ${OUTDIR}/images/zImage \
+ -drive file=${OUTDIR}/images/rootfs.ext2,if=scsi \
+ -append "root=/dev/sda console=ttyAMA0,115200" \
+ -serial stdio -net nic,model=rtl8139 -net user
diff --git a/test-all b/test-all
new file mode 100755
index 0000000..21fdb2b
--- /dev/null
+++ b/test-all
@@ -0,0 +1,34 @@
+#!/bin/sh
+
+set -e
+set -u
+
+usage()
+{
+ echo "Usage: $0 {build|run}"
+}
+
+if [ -z "$1" ]; then
+ usage
+ exit 1
+fi
+
+for INIT in bb sv; do
+ for DEV in static mdev_only dyn_devtmpfs dyn_eudev dyn_mdev; do
+ TARGET="${INIT}_${DEV}"
+ case "$1" in
+ build)
+ make O=bld/${TARGET} test_${TARGET}_defconfig
+ make O=bld/${TARGET}
+ ;;
+ run)
+ echo "================= running ${TARGET} ==================="
+ ./run bld/${TARGET}
+ echo "----------------- finished ${TARGET} -------------------"
+ ;;
+ *)
+ usage
+ exit 1
+ esac
+ done
+done
--
1.9.1
^ permalink raw reply related [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab
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
0 siblings, 0 replies; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 9:12 UTC (permalink / raw)
To: buildroot
On 08-09-15 23:28, Luca Ceresoli wrote:
> We are going to launch mdev from inittab, to have dynamic /dev without
> devtmpfs. However, mdev needs /sys to detect devices.
>
> So, mount /sys before the place where mdev will be activated.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Not tested, but I trust patch 6/6 :-)
Regards,
Arnout
> ---
> package/busybox/inittab | 1 +
> package/sysvinit/inittab | 13 +++++++------
> system/skeleton/etc/fstab | 1 -
> 3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/package/busybox/inittab b/package/busybox/inittab
> index b1892c1..6703fc5 100644
> --- a/package/busybox/inittab
> +++ b/package/busybox/inittab
> @@ -15,6 +15,7 @@
>
> # Startup the system
> null::sysinit:/bin/mount -t proc proc /proc
> +null::sysinit:/bin/mount -t sysfs sysfs /sys
> null::sysinit:/bin/mount -o remount,rw /
> null::sysinit:/bin/mkdir -p /dev/pts
> null::sysinit:/bin/mkdir -p /dev/shm
> diff --git a/package/sysvinit/inittab b/package/sysvinit/inittab
> index fc0c9b5..6ebf6fa 100644
> --- a/package/sysvinit/inittab
> +++ b/package/sysvinit/inittab
> @@ -5,12 +5,13 @@
> id:3:initdefault:
>
> si0::sysinit:/bin/mount -t proc proc /proc
> -si1::sysinit:/bin/mount -o remount,rw /
> -si2::sysinit:/bin/mkdir -p /dev/pts
> -si3::sysinit:/bin/mkdir -p /dev/shm
> -si4::sysinit:/bin/mount -a
> -si5::sysinit:/bin/hostname -F /etc/hostname
> -si6::sysinit:/etc/init.d/rcS
> +si1::sysinit:/bin/mount -t sysfs sysfs /sys
> +si2::sysinit:/bin/mount -o remount,rw /
> +si3::sysinit:/bin/mkdir -p /dev/pts
> +si4::sysinit:/bin/mkdir -p /dev/shm
> +si5::sysinit:/bin/mount -a
> +si6::sysinit:/bin/hostname -F /etc/hostname
> +si7::sysinit:/etc/init.d/rcS
>
> # S0:1:respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
>
> diff --git a/system/skeleton/etc/fstab b/system/skeleton/etc/fstab
> index 2b418a0..489f256 100644
> --- a/system/skeleton/etc/fstab
> +++ b/system/skeleton/etc/fstab
> @@ -5,4 +5,3 @@ devpts /dev/pts devpts defaults,gid=5,mode=620 0 0
> tmpfs /dev/shm tmpfs mode=0777 0 0
> tmpfs /tmp tmpfs mode=1777 0 0
> tmpfs /run tmpfs mode=0755,nosuid,nodev 0 0
> -sysfs /sys sysfs defaults 0 0
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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 9:34 ` Arnout Vandecappelle
2015-09-09 11:29 ` Thomas Petazzoni
2 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 9:21 UTC (permalink / raw)
To: buildroot
On 08-09-15 23:28, Luca Ceresoli wrote:
> +++ b/package/busybox/inittab
> @@ -16,6 +16,7 @@
> # Startup the system
> null::sysinit:/bin/mount -t proc proc /proc
> null::sysinit:/bin/mount -t sysfs sysfs /sys
> +#null::sysinit:/sbin/activate-mdev
Excuse my stupidity, but wouldn't it be enough to add the following here:
null::sysinit:/bin/mount -t tmpfs mdev /dev
and keep on using S10mdev? That is less invasive, and it should work since it's
more or less the same as what is done in the cpio/initramfs case.
Regards,
Arnout
> null::sysinit:/bin/mount -o remount,rw /
> null::sysinit:/bin/mkdir -p /dev/pts
> null::sysinit:/bin/mkdir -p /dev/shm
> diff --git a/package/skeleton/skeleton.mk b/package/skeleton/skeleton.mk
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs)
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (5 preceding siblings ...)
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 ` Arnout Vandecappelle
2015-09-09 11:30 ` Thomas Petazzoni
2015-09-14 21:03 ` Peter Korsgaard
7 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 9:26 UTC (permalink / raw)
To: buildroot
On 08-09-15 23:28, Luca Ceresoli wrote:
> There is one rough edge that I'd like to have comments about: variable
> naming. The new method implemented by this patchset is dynamic and uses
> mdev, so it should ba named BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV and
> described in kconfig as "dynamic using mdev". But hey, that name and
> description are already used for the current "devtmpfs + mdev" method! So
> we might want to rename all variables to encompass the new use case in a
> clean way. Thid would also imply lagacy management etc.
Since we don't like legacy management :-) I'd propose to say that DYNAMIC
actually means DEVTMPFS. So the new option would be called
BR2_ROOTFS_DEVICE_CREATION_MDEV: it's not devtmpfs, and there's no need for the
explicit 'only' part.
What do you think?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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 9:34 ` Arnout Vandecappelle
2015-09-09 11:23 ` Thomas Petazzoni
2015-09-09 11:29 ` Thomas Petazzoni
2 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 9:34 UTC (permalink / raw)
To: buildroot
On 08-09-15 23:28, Luca Ceresoli wrote:
> 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.
Actually, I don't think this is a good idea: we're asking the user to configure
a static device table which is not going to be used anyway.
I think it's better to move /dev/null and /dev/console to device_table.txt -
i.e., include them in every rootfs. It just increases the size with a few
hundred bytes, it doesn't hurt because devtmpfs is normally automounted over it
right away, and it is better for the cpio/initramfs case because you won't get
the 'Unable to open initial console' message anymore (I think). Plus, the
redirects can be removed from fs/cpio/init since they'll be automatic.
What do the other developers think?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev}
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
0 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 9:40 UTC (permalink / raw)
To: buildroot
On 08-09-15 23:28, Luca Ceresoli wrote:
> We're going to introduce /dev management with mdev only (no devtmpfs),
> which will be called "Dynamic using mdev only".
>
> In preparation to that addition, clarify the current /dev managements
> systems which use devtmpfs with an additional tool. Otherwise
> "Dynamic using mdev" and "Dynamic using mdev only" wight look quite
> undistinguishable to mortals...
I would squash the change to the manual with patch 5/6 and squash the changes
to the Config.in prompts into patch 3/6, since these changes are related.
But the updated text looks good to me, so:
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Oh, perhaps you could add a brief help text to the choice options? You can more
or less copy and paste the text from the manual. If you do add help text, do it
as a separate patch at the end of the series so it doesn't have to be updated
again after the introduction of mdev-only.
Regards,
Arnout
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> ---
> docs/manual/configure.txt | 7 ++++---
> system/Config.in | 4 ++--
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
> index dd34eef..997be2b 100644
> --- a/docs/manual/configure.txt
> +++ b/docs/manual/configure.txt
> @@ -295,7 +295,7 @@ different solutions to handle the +/dev+ directory :
> responsibility to enable those two options (if you fail to do so,
> your Buildroot system will not boot).
>
> - * The third solution is *Dynamic using mdev*. This method also relies
> + * The third solution is *Dynamic using devtmpfs + mdev*. This method also relies
> on the _devtmpfs_ virtual filesystem detailed above (so the
> requirement to have +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+
> enabled in the kernel configuration still apply), but adds the
> @@ -314,7 +314,7 @@ different solutions to handle the +/dev+ directory :
> about +mdev+ and the syntax of its configuration file, see
> http://git.busybox.net/busybox/tree/docs/mdev.txt.
>
> - * The fourth solution is *Dynamic using eudev*. This method also
> + * The fourth solution is *Dynamic using devtmpfs + eudev*. This method also
> relies on the _devtmpfs_ virtual filesystem detailed above, but
> adds the +eudev+ userspace daemon on top of it. +eudev+ is a daemon
> that runs in the background, and gets called by the kernel when a
> @@ -327,7 +327,8 @@ different solutions to handle the +/dev+ directory :
> The Buildroot developers recommendation is to start with the *Dynamic
> using devtmpfs only* solution, until you have the need for userspace
> to be notified when devices are added/removed, or if firmwares are
> -needed, in which case *Dynamic using mdev* is usually a good solution.
> +needed, in which case *Dynamic using devtmpfs + mdev* is usually a
> +good solution.
>
> Note that if +systemd+ is chosen as init system, /dev management will
> be performed by the +udev+ program provided by +systemd+.
> diff --git a/system/Config.in b/system/Config.in
> index fad829d..5bf5048 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -110,11 +110,11 @@ config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
> bool "Dynamic using devtmpfs only"
>
> config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV
> - bool "Dynamic using mdev"
> + bool "Dynamic using devtmpfs + mdev"
> select BR2_PACKAGE_BUSYBOX
>
> config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV
> - bool "Dynamic using eudev"
> + bool "Dynamic using devtmpfs + eudev"
> depends on BR2_USE_WCHAR
> depends on !BR2_STATIC_LIBS
> depends on BR2_USE_MMU # eudev
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" /dev management
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
0 siblings, 0 replies; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 10:39 UTC (permalink / raw)
To: buildroot
Hi Luca,
On 08-09-15 23:28, Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> ---
> docs/manual/configure.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
> index 997be2b..ea78d96 100644
> --- a/docs/manual/configure.txt
> +++ b/docs/manual/configure.txt
> @@ -324,6 +324,17 @@ different solutions to handle the +/dev+ directory :
> daemon used in most desktop Linux distributions, which is now part
> of Systemd. For more details, see http://en.wikipedia.org/wiki/Udev.
>
For consistency with the way it's ordered in menuconfig, I'd move the new
bullet point to the second place in the list. That does mean you have to update
all the second, third, fourth bullets but that's no biggy I guess.
> + * *Dynamic using mdev only* uses +mdev+ and allows to use all the
> + features of +mdev+, including dynamic device creation and firmware
> + handling, but does not use _devtmpfs_.
If you move it as the second bullet, the explanation about mdev should be moved
to here as well. So I propose the following rephrased bullet point (which
includes a bunch of minor fixes to the text):
* The second solution is *Dynamic using mdev only*. +mdev+ is a helper program
that is part of BusyBox. The kernel will call it every time a device is added
or removed, and +mdev+ will create the appropriate device node in +/dev+.
Thanks to the +/etc/mdev.conf+ configuration file, +mdev+ can be configured
to, for example, set specific permissions or ownership on a device file, call
a script or application whenever a device appears or disappears, etc.
Basically, it allows _userspace_ to react on device addition and removal
events. +mdev+ can for example be used to automatically load kernel modules
when devices appear on the system. +mdev+ is also important if you have
devices that require a firmware blob to be loaded: it will be responsible
for pushing the firmware contents to the kernel. +mdev+ is a lightweight
implementation (with fewer features) of +udev+. For more details
about +mdev+ and the syntax of its configuration file, see
http://git.busybox.net/busybox/tree/docs/mdev.txt.
+
If you have to use a kernel older than 2.6.32, this is the only option to
have dynamic +/dev+ management, although it can be used with more recent
versions of the kernel as well. If you build your Linux kernel outside of
Buildroot, you should disable +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+
in your kernel configuration. When Buildroot is in charge of building the
Linux kernel, it disables them automatically.
Clearly, if you take this proposal, also the devtmpfs+mdev option has to be
updated a little to avoid duplication.
Regards,
Arnout
> + If you have to use a kernel older than 2.6.32 this is the only
> + option to have dynamic /dev management, although it can be used
> + with more recent versions of the kernel as well.
> + If you build your Linux kernel outside of Buildroot, you should
> + disable +CONFIG_DEVTMPFS+ and +CONFIG_DEVTMPFS_MOUNT+ in your kernel
> + configuration. When Buildroot is in charge of building the Linux
> + kernel, it disables them automatically.
> +
> The Buildroot developers recommendation is to start with the *Dynamic
> using devtmpfs only* solution, until you have the need for userspace
> to be notified when devices are added/removed, or if firmwares are
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev}
2015-09-09 9:40 ` Arnout Vandecappelle
@ 2015-09-09 10:53 ` Luca Ceresoli
2015-09-09 10:54 ` Arnout Vandecappelle
0 siblings, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-09 10:53 UTC (permalink / raw)
To: buildroot
Dear Arnout,
thanks for you review.
Arnout Vandecappelle wrote:
> On 08-09-15 23:28, Luca Ceresoli wrote:
>> We're going to introduce /dev management with mdev only (no devtmpfs),
>> which will be called "Dynamic using mdev only".
>>
>> In preparation to that addition, clarify the current /dev managements
>> systems which use devtmpfs with an additional tool. Otherwise
>> "Dynamic using mdev" and "Dynamic using mdev only" wight look quite
>> undistinguishable to mortals...
>
> I would squash the change to the manual with patch 5/6 and squash the changes
> to the Config.in prompts into patch 3/6, since these changes are related.
Well, to be picky about bisectability, the changes in this patch should
stay together. Otherwise at some commit we'd have "Dynamic using
devtmpfs + mdev" in kconfig but "Dynamic using mdev" in the docs.
>
> But the updated text looks good to me, so:
> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
>
> Oh, perhaps you could add a brief help text to the choice options? You can more
> or less copy and paste the text from the manual. If you do add help text, do it
> as a separate patch at the end of the series so it doesn't have to be updated
> again after the introduction of mdev-only.
Good idea, I'll do it in the next iteration.
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev}
2015-09-09 10:53 ` Luca Ceresoli
@ 2015-09-09 10:54 ` Arnout Vandecappelle
0 siblings, 0 replies; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 10:54 UTC (permalink / raw)
To: buildroot
On 09-09-15 12:53, Luca Ceresoli wrote:
> Dear Arnout,
>
> thanks for you review.
>
> Arnout Vandecappelle wrote:
>> On 08-09-15 23:28, Luca Ceresoli wrote:
>>> We're going to introduce /dev management with mdev only (no devtmpfs),
>>> which will be called "Dynamic using mdev only".
>>>
>>> In preparation to that addition, clarify the current /dev managements
>>> systems which use devtmpfs with an additional tool. Otherwise
>>> "Dynamic using mdev" and "Dynamic using mdev only" wight look quite
>>> undistinguishable to mortals...
>>
>> I would squash the change to the manual with patch 5/6 and squash the changes
>> to the Config.in prompts into patch 3/6, since these changes are related.
>
> Well, to be picky about bisectability, the changes in this patch should
> stay together. Otherwise at some commit we'd have "Dynamic using
> devtmpfs + mdev" in kconfig but "Dynamic using mdev" in the docs.
OK, so then keep this patch and include my Reviewed-by.
Regards,
Arnout
[snip]
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 9:34 ` Arnout Vandecappelle
@ 2015-09-09 11:23 ` Thomas Petazzoni
0 siblings, 0 replies; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-09 11:23 UTC (permalink / raw)
To: buildroot
Arnout, Luca,
On Wed, 9 Sep 2015 11:34:48 +0200, Arnout Vandecappelle wrote:
> On 08-09-15 23:28, Luca Ceresoli wrote:
> > 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.
>
> Actually, I don't think this is a good idea: we're asking the user to configure
> a static device table which is not going to be used anyway.
>
> I think it's better to move /dev/null and /dev/console to device_table.txt -
> i.e., include them in every rootfs. It just increases the size with a few
> hundred bytes, it doesn't hurt because devtmpfs is normally automounted over it
> right away, and it is better for the cpio/initramfs case because you won't get
> the 'Unable to open initial console' message anymore (I think). Plus, the
> redirects can be removed from fs/cpio/init since they'll be automatic.
>
> What do the other developers think?
I would prefer to keep /dev/null and /dev/console in a special device
table, used only for the mdev without devtmpfs case, but not make it
configurable.
So, I would actually not make the option BR2_ROOTFS_STATIC_DEVICE_TABLE
visible for the BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY case, and
instead force using a minimal, hard-coded, device table in this case.
There is no reason whatsoever to have anything else but /dev/null
and /dev/zero in the mdev without devtmpfs case.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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 9:34 ` Arnout Vandecappelle
@ 2015-09-09 11:29 ` Thomas Petazzoni
2015-09-09 20:33 ` Arnout Vandecappelle
2015-09-14 16:05 ` Luca Ceresoli
2 siblings, 2 replies; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-09 11:29 UTC (permalink / raw)
To: buildroot
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.
> 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
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?
> 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)
> 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.
> ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y)
> # Find commented line, if any, and remove leading '#'s
> define SKELETON_SYSTEM_REMOUNT_RW
> @@ -153,6 +154,20 @@ define SKELETON_SYSTEM_REMOUNT_RW
> endef
> endif
> TARGET_FINALIZE_HOOKS += SKELETON_SYSTEM_REMOUNT_RW
> +
> +ifeq ($(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV_ONLY),y)
> +# Find commented line, if any, and remove leading '#'s
> +define SKELETON_SYSTEM_EARLY_MDEV
> + $(SED) '/^#.*sbin\/activate-mdev$$/s~^#\+~~' $(TARGET_DIR)/etc/inittab
> +endef
> +else
> +# Find uncommented line, if any, and add a leading '#'
> +define SKELETON_SYSTEM_EARLY_MDEV
> + $(SED) '/^[^#].*sbin\/activate-mdev$$/s~^~#~' $(TARGET_DIR)/etc/inittab
> +endef
> +endif
> +TARGET_FINALIZE_HOOKS += SKELETON_SYSTEM_EARLY_MDEV
> +
> endif # BR2_INIT_BUSYBOX || BR2_INIT_SYSV
>
> endif # BR2_ROOTFS_SKELETON_DEFAULT
> diff --git a/package/sysvinit/inittab b/package/sysvinit/inittab
> index 6ebf6fa..5abca7f 100644
> --- a/package/sysvinit/inittab
> +++ b/package/sysvinit/inittab
> @@ -6,12 +6,13 @@ id:3:initdefault:
>
> si0::sysinit:/bin/mount -t proc proc /proc
> si1::sysinit:/bin/mount -t sysfs sysfs /sys
> -si2::sysinit:/bin/mount -o remount,rw /
> -si3::sysinit:/bin/mkdir -p /dev/pts
> -si4::sysinit:/bin/mkdir -p /dev/shm
> -si5::sysinit:/bin/mount -a
> -si6::sysinit:/bin/hostname -F /etc/hostname
> -si7::sysinit:/etc/init.d/rcS
> +si2::sysinit:/sbin/activate-mdev
> +si3::sysinit:/bin/mount -o remount,rw /
> +si4::sysinit:/bin/mkdir -p /dev/pts
> +si5::sysinit:/bin/mkdir -p /dev/shm
> +si6::sysinit:/bin/mount -a
> +si7::sysinit:/bin/hostname -F /etc/hostname
> +si8::sysinit:/etc/init.d/rcS
>
> # S0:1:respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
>
> 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.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs)
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
@ 2015-09-09 11:30 ` Thomas Petazzoni
0 siblings, 0 replies; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-09 11:30 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 9 Sep 2015 11:26:26 +0200, Arnout Vandecappelle wrote:
> On 08-09-15 23:28, Luca Ceresoli wrote:
> > There is one rough edge that I'd like to have comments about: variable
> > naming. The new method implemented by this patchset is dynamic and uses
> > mdev, so it should ba named BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV and
> > described in kconfig as "dynamic using mdev". But hey, that name and
> > description are already used for the current "devtmpfs + mdev" method! So
> > we might want to rename all variables to encompass the new use case in a
> > clean way. Thid would also imply lagacy management etc.
>
> Since we don't like legacy management :-) I'd propose to say that DYNAMIC
> actually means DEVTMPFS. So the new option would be called
> BR2_ROOTFS_DEVICE_CREATION_MDEV: it's not devtmpfs, and there's no need for the
> explicit 'only' part.
>
> What do you think?
I agree. I would prefer to not change the name of existing options.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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
0 siblings, 2 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-09 12:29 UTC (permalink / raw)
To: buildroot
Dear Arnout,
Arnout Vandecappelle wrote:
> On 08-09-15 23:28, Luca Ceresoli wrote:
>> +++ b/package/busybox/inittab
>> @@ -16,6 +16,7 @@
>> # Startup the system
>> null::sysinit:/bin/mount -t proc proc /proc
>> null::sysinit:/bin/mount -t sysfs sysfs /sys
>> +#null::sysinit:/sbin/activate-mdev
>
> Excuse my stupidity, but wouldn't it be enough to add the following here:
>
> null::sysinit:/bin/mount -t tmpfs mdev /dev
>
> and keep on using S10mdev? That is less invasive, and it should work since it's
> more or less the same as what is done in the cpio/initramfs case.
Good idea, with a couple caveats.
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.
I'll check if sysvinit init has any issues.
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?
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 12:29 ` Luca Ceresoli
@ 2015-09-09 12:32 ` Arnout Vandecappelle
2015-09-09 13:54 ` Thomas Petazzoni
1 sibling, 0 replies; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 12:32 UTC (permalink / raw)
To: buildroot
On 09-09-15 14:29, Luca Ceresoli wrote:
> 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?
I'd prefer to have logging before mdev, so any fallout from mdev will appear in
the logs. So for me, S02mdev is fine.
In my mdev-using projects I usually have a custom mdev script (to do more
extensive coldplugging) and I also move it to S02.
Regards,
Arnout
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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 20:53 ` Peter Korsgaard
1 sibling, 2 replies; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-09 13:54 UTC (permalink / raw)
To: buildroot
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.
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.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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
1 sibling, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-09 20:33 UTC (permalink / raw)
To: buildroot
On 09-09-15 13:29, 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.
Right! So:
define BUSYBOX_DEVICES
/dev/console c 666 0 0 5 1 - - -
/dev/null c 666 0 0 1 3 0 0 -
endef
Regards,
Arnout
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 13:54 ` Thomas Petazzoni
@ 2015-09-14 13:47 ` Luca Ceresoli
2015-09-14 22:23 ` Arnout Vandecappelle
2015-09-14 20:53 ` Peter Korsgaard
1 sibling, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-14 13:47 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 11:29 ` Thomas Petazzoni
2015-09-09 20:33 ` Arnout Vandecappelle
@ 2015-09-14 16:05 ` Luca Ceresoli
2015-09-14 19:34 ` Thomas Petazzoni
1 sibling, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-14 16:05 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 20:33 ` Arnout Vandecappelle
@ 2015-09-14 16:07 ` Luca Ceresoli
0 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-14 16:07 UTC (permalink / raw)
To: buildroot
Dear Arnout,
Arnout Vandecappelle wrote:
> On 09-09-15 13:29, 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.
>
> Right! So:
>
> define BUSYBOX_DEVICES
> /dev/console c 666 0 0 5 1 - - -
> /dev/null c 666 0 0 1 3 0 0 -
> endef
Good idea, this saves creating a new device table.
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 16:05 ` Luca Ceresoli
@ 2015-09-14 19:34 ` Thomas Petazzoni
2015-09-14 20:19 ` Arnout Vandecappelle
0 siblings, 1 reply; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-14 19:34 UTC (permalink / raw)
To: buildroot
Dear Luca Ceresoli,
On Mon, 14 Sep 2015 18:05:52 +0200, Luca Ceresoli wrote:
> But now I removed that patch, and replaced with a different
> implementation based on Arnout's suggestion of using BUSYBOX_DEVICES.
I am not sure using BUSYBOX_DEVICES is fully correct. The reason
why /dev/console is needed is *not* because of Busybox, but because of
the kernel that is opening /dev/console before handing control over
to the init application:
http://lxr.free-electrons.com/source/init/main.c#L1011
If you do BUSYBOX_DEVICES with just /dev/console, then you will also
need a SYSVINIT_DEVICES with just /dev/console.
Though I admit my comment here is mainly nitpicking :)
> > 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.
Great!
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 19:34 ` Thomas Petazzoni
@ 2015-09-14 20:19 ` Arnout Vandecappelle
2015-09-15 22:07 ` Luca Ceresoli
0 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-14 20:19 UTC (permalink / raw)
To: buildroot
On 14-09-15 21:34, Thomas Petazzoni wrote:
> Dear Luca Ceresoli,
>
> On Mon, 14 Sep 2015 18:05:52 +0200, Luca Ceresoli wrote:
>
>> But now I removed that patch, and replaced with a different
>> implementation based on Arnout's suggestion of using BUSYBOX_DEVICES.
>
> I am not sure using BUSYBOX_DEVICES is fully correct. The reason
> why /dev/console is needed is *not* because of Busybox, but because of
> the kernel that is opening /dev/console before handing control over
> to the init application:
>
> http://lxr.free-electrons.com/source/init/main.c#L1011
>
> If you do BUSYBOX_DEVICES with just /dev/console, then you will also
> need a SYSVINIT_DEVICES with just /dev/console.
>
> Though I admit my comment here is mainly nitpicking :)
But of course you are right. This is part of the system/skeleton handling, and
now skeleton is a package, we can make it part of SKELETON_DEVICES.
Regards,
Arnout
>
>>> 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.
>
> Great!
>
> Thanks!
>
> Thomas
>
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-09 13:54 ` Thomas Petazzoni
2015-09-14 13:47 ` Luca Ceresoli
@ 2015-09-14 20:53 ` Peter Korsgaard
2015-09-14 21:34 ` Thomas Petazzoni
1 sibling, 1 reply; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-14 20:53 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> 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.
It doesn't:
git grep log mdev.c
mdev.c://usage: "If /dev/mdev.log file exists, debug log will be appended to it."
mdev.c:static void open_mdev_log(const char *seq, unsigned my_pid)
mdev.c: int logfd = open("mdev.log", O_WRONLY | O_APPEND);
mdev.c: if (logfd >= 0) {
mdev.c: xmove_fd(logfd, STDERR_FILENO);
mdev.c: open_mdev_log(seq, my_pid);
So only to stderr (and /dev/mdev.log if it exists).
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs)
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
` (6 preceding siblings ...)
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
@ 2015-09-14 21:03 ` Peter Korsgaard
7 siblings, 0 replies; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-14 21:03 UTC (permalink / raw)
To: buildroot
>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
> Hi,
> this patchset adds a new /dev management mechanism, using mdev for
> dynamic device creation but without relying on devtmpfs.
> The main motivation is the need of dynamic /dev management and/or firmware
> loading assisted by mdev on targets that are bound to kernels < 2.6.32,
> and thus cannot use devtmpfs.
Is combining such old (<2009) kernel with modern userspace really a good
idea?
git grep -l _AT_LEAST package/ | wc -l
48
But that is most likely not all of them, as none of the autobuilders use
such ancient kernel headers.
How old is < 2.6.32? If you look@the commit adding devtmpfs to the
kernel, it seems quite self contained and easy to backport:
git show --stat --oneline 2b2af54a5bb6f7e8
2b2af54 Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev
drivers/base/Kconfig | 25 ++++
drivers/base/Makefile | 1 +
drivers/base/base.h | 6 +
drivers/base/core.c | 3 +
drivers/base/devtmpfs.c | 367 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/base/init.c | 1 +
include/linux/device.h | 10 ++
include/linux/shmem_fs.h | 3 +
init/do_mounts.c | 2 +-
init/main.c | 2 +
mm/shmem.c | 9 +-
11 files changed, 422 insertions(+), 7 deletions(-)
Have you considered doing that instead?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 20:53 ` Peter Korsgaard
@ 2015-09-14 21:34 ` Thomas Petazzoni
2015-09-14 21:38 ` Peter Korsgaard
0 siblings, 1 reply; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-14 21:34 UTC (permalink / raw)
To: buildroot
Dear Peter Korsgaard,
On Mon, 14 Sep 2015 22:53:30 +0200, Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
>
> > 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.
>
> It doesn't:
>
> git grep log mdev.c
> mdev.c://usage: "If /dev/mdev.log file exists, debug log will be appended to it."
> mdev.c:static void open_mdev_log(const char *seq, unsigned my_pid)
> mdev.c: int logfd = open("mdev.log", O_WRONLY | O_APPEND);
> mdev.c: if (logfd >= 0) {
> mdev.c: xmove_fd(logfd, STDERR_FILENO);
> mdev.c: open_mdev_log(seq, my_pid);
>
> So only to stderr (and /dev/mdev.log if it exists).
Then we can safely start mdev before the syslog/klogd stuff, right?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 21:34 ` Thomas Petazzoni
@ 2015-09-14 21:38 ` Peter Korsgaard
2015-09-15 7:30 ` Thomas Petazzoni
0 siblings, 1 reply; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-14 21:38 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> git grep log mdev.c
>> mdev.c://usage: "If /dev/mdev.log file exists, debug log will be appended to it."
>> mdev.c:static void open_mdev_log(const char *seq, unsigned my_pid)
>> mdev.c: int logfd = open("mdev.log", O_WRONLY | O_APPEND);
>> mdev.c: if (logfd >= 0) {
>> mdev.c: xmove_fd(logfd, STDERR_FILENO);
>> mdev.c: open_mdev_log(seq, my_pid);
>>
>> So only to stderr (and /dev/mdev.log if it exists).
> Then we can safely start mdev before the syslog/klogd stuff, right?
Yes, but I still question the need for all of this work in the first
place.
Is there any reason for NOT using devtmpfs if it is available? And if it
isn't, is making Buildroot more complicated better than asking people to
backport devtmpfs support and/or upgrade to a newer kernel? We certainly
don't test such old kernel headers in the autobuilders.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 13:47 ` Luca Ceresoli
@ 2015-09-14 22:23 ` Arnout Vandecappelle
2015-09-15 22:35 ` Luca Ceresoli
0 siblings, 1 reply; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-14 22:23 UTC (permalink / raw)
To: buildroot
On 14-09-15 15:47, Luca Ceresoli wrote:
> Dear Thomas,
>
> Thomas Petazzoni wrote:
>> Dear Luca Ceresoli,
>>
>> On Wed, 9 Sep 2015 14:29:36 +0200, Luca Ceresoli wrote:
[snip]
>>> 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.
mdev doesn't but any script it calls might.
Also, if a crash happens during mdev coldplugging, it's an advantage if the
kernel messages can be captured by syslog.
So I'd prefer to keep syslog before mdev.
FYI: systemd starts journald and udev in parallel (at least as far as I can
make out from the service files).
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 21:38 ` Peter Korsgaard
@ 2015-09-15 7:30 ` Thomas Petazzoni
2015-09-15 8:09 ` Peter Korsgaard
0 siblings, 1 reply; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-15 7:30 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 14 Sep 2015 23:38:17 +0200, Peter Korsgaard wrote:
> > Then we can safely start mdev before the syslog/klogd stuff, right?
>
> Yes, but I still question the need for all of this work in the first
> place.
On my side, I don't. Some people are still forced to use 2.6.x kernels
older than 2.6.32, and if Luca (who is a knowledgeable and
skilled developer) has such a need, I'm sure it means there is a silent
group of people stuck with prehistoric kernels that would benefit from
this.
In addition, the changes that Luca is proposing are very
self-contained, and often shared with the other /dev management
solutions. So I don't see a lot of additional complexity in what Luca
is proposing.
> Is there any reason for NOT using devtmpfs if it is available?
Well the point is precisely that it isn't.
> And if it isn't, is making Buildroot more complicated better than
> asking people to backport devtmpfs support and/or upgrade to a newer
> kernel?
Luca is using a vendor-specific kernel in which the entire SoC support
is not in mainline. So moving to a newer kernel is simply not an option
(or an option with a several man-years effort, which for many companies
is the same as "not an option").
I'm not sure how complicated it is to backport devtmpfs. However I
would suspect that it isn't that easy.
> We certainly don't test such old kernel headers in the autobuilders.
Indeed, we don't. But we could ask Luca, as part of this patch series,
to help us add such a toolchain in our autobuilders. So far, Luca has
provided some patches that are perfectly documented, along with test
cases and test scripts to validate the booting with all possible /dev
management situations. To me, the perfectness of Luca's contribution is
a good enough argument to merge this feature :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 7:30 ` Thomas Petazzoni
@ 2015-09-15 8:09 ` Peter Korsgaard
2015-09-15 9:41 ` Thomas Petazzoni
2015-09-15 22:31 ` Luca Ceresoli
0 siblings, 2 replies; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-15 8:09 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> Yes, but I still question the need for all of this work in the first
>> place.
> On my side, I don't. Some people are still forced to use 2.6.x kernels
> older than 2.6.32, and if Luca (who is a knowledgeable and
> skilled developer) has such a need, I'm sure it means there is a silent
> group of people stuck with prehistoric kernels that would benefit from
> this.
Sure, I get that. I just question the sensibility of combining a 6+ year
old kernel with modern user space.
> In addition, the changes that Luca is proposing are very
> self-contained, and often shared with the other /dev management
> solutions. So I don't see a lot of additional complexity in what Luca
> is proposing.
I do, it is yet another slightly different variant of the /dev
handling to confuse new users and complicate the build logic.
I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
either.
>> Is there any reason for NOT using devtmpfs if it is available?
> Well the point is precisely that it isn't.
What I meant is actually if this option is only useful for the (few?)
Buildroot users with <2.6.32 kernels that want mdev support, or also for
others?
> Luca is using a vendor-specific kernel in which the entire SoC support
> is not in mainline. So moving to a newer kernel is simply not an option
> (or an option with a several man-years effort, which for many companies
> is the same as "not an option").
I get that.
> I'm not sure how complicated it is to backport devtmpfs. However I
> would suspect that it isn't that easy.
Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
kernel. To me it looks quite self contained, so backporting it to
something close to 2.6.32 doesn't look too bad.
>> We certainly don't test such old kernel headers in the autobuilders.
> Indeed, we don't. But we could ask Luca, as part of this patch series,
> to help us add such a toolchain in our autobuilders.
I'm not sure I'm really interested in seeing a bunch of patches adding
'depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_<old>' / comments to
packages.
> So far, Luca has provided some patches that are perfectly documented,
> along with test cases and test scripts to validate the booting with
> all possible /dev management situations. To me, the perfectness of
> Luca's contribution is a good enough argument to merge this feature
> :-)
I agree, the patches themselves are very nice work!
But I still need to be convinced that adding this other mdev variant is
the best tradeoff between:
- Adding the patches
- Ask people to backport devtmpfs to their kernel
- Ask people to handle it in a post-build script
- Ask people to add a initramfs mounting a tmpfs on /dev + mknod before
executing init
- Asking people to stick with user space of the same "maturity" ;) as
their kernel
If there's other people interested in this feature, then it would be
nice to hear from you.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 8:09 ` Peter Korsgaard
@ 2015-09-15 9:41 ` Thomas Petazzoni
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 22:31 ` Luca Ceresoli
1 sibling, 1 reply; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-15 9:41 UTC (permalink / raw)
To: buildroot
Hello,
On Tue, 15 Sep 2015 10:09:39 +0200, Peter Korsgaard wrote:
> > On my side, I don't. Some people are still forced to use 2.6.x kernels
> > older than 2.6.32, and if Luca (who is a knowledgeable and
> > skilled developer) has such a need, I'm sure it means there is a silent
> > group of people stuck with prehistoric kernels that would benefit from
> > this.
>
> Sure, I get that. I just question the sensibility of combining a 6+ year
> old kernel with modern user space.
Well, it is quite understandable that Luca would like to use a recent
and modern Buildroot for his project. But since Buildroot is a bundle
of a build infrastructure *and* package recipes, you can't get a recent
and modern Buildroot without getting a recent and modern user-space.
> > In addition, the changes that Luca is proposing are very
> > self-contained, and often shared with the other /dev management
> > solutions. So I don't see a lot of additional complexity in what Luca
> > is proposing.
>
> I do, it is yet another slightly different variant of the /dev
> handling to confuse new users and complicate the build logic.
Well, the /dev handling already has a number of different options, and
the user must anyway understand a little bit how a Linux system is
working to make a sensible choice between the different options. The
default is sane, and will remain the same, so that clueless users
continue to get the same experience/result.
I don't think a new variant of /dev management is that more complicated
than the "OpenMP support", "stack smashing protection support" or "LTO
support" options we have in the Toolchain menu.
> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
> either.
If it "isn't non trivial", then it is trivial, right ? :-)
> >> Is there any reason for NOT using devtmpfs if it is available?
>
> > Well the point is precisely that it isn't.
>
> What I meant is actually if this option is only useful for the (few?)
> Buildroot users with <2.6.32 kernels that want mdev support, or also for
> others?
Yes, it is probably only for people using kernels older than 2.6.32 who
need mdev for automatic module loading, or firmware loading.
There might be more users of such a thing that there are users of some
of our weird packages. Admitted, a package is just a package and
doesn't add any complexity to the core. But the additional complexity
brought by Luca's work is relatively small. And his work has in fact
uncovered a few issues in our existing code (the fact that we redirect
the output of all inittab commands to /dev/null, and that some of them
are in fact failing without us noticing).
> > I'm not sure how complicated it is to backport devtmpfs. However I
> > would suspect that it isn't that easy.
>
> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
> kernel. To me it looks quite self contained, so backporting it to
> something close to 2.6.32 doesn't look too bad.
Indeed. I wonder how many dependencies on other patches it has, though.
Luca, can you give it a try and see if it would work for you?
> >> We certainly don't test such old kernel headers in the autobuilders.
>
> > Indeed, we don't. But we could ask Luca, as part of this patch series,
> > to help us add such a toolchain in our autobuilders.
>
> I'm not sure I'm really interested in seeing a bunch of patches adding
> 'depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_<old>' / comments to
> packages.
Right, this I understand. We could keep the current state of things:
dependencies are only for >= 3.x kernels. So if something builds with
2.6.38 but not 2.6.32, then we don't care, and we make it depend on >=
3.x. Though I agree some people using 2.6.35 might complain, as they
can technically build that thing.
> But I still need to be convinced that adding this other mdev variant is
> the best tradeoff between:
>
> - Adding the patches
>
> - Ask people to backport devtmpfs to their kernel
>
> - Ask people to handle it in a post-build script
>
> - Ask people to add a initramfs mounting a tmpfs on /dev + mknod before
> executing init
>
> - Asking people to stick with user space of the same "maturity" ;) as
> their kernel
>
> If there's other people interested in this feature, then it would be
> nice to hear from you.
I agree getting more feedback from other potential users would be good.
However, I fear that many of the people who are stuck with old crappy
kernels are also in companies that are not necessarily very open, and
we may simply never hear from them.
So, as suggested above, Luca, can you try to backport devtmpfs? If that
solves the problem, then it's probably a good enough solution.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 9:41 ` Thomas Petazzoni
@ 2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
` (2 more replies)
0 siblings, 3 replies; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-15 12:01 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> Sure, I get that. I just question the sensibility of combining a 6+ year
>> old kernel with modern user space.
> Well, it is quite understandable that Luca would like to use a recent
> and modern Buildroot for his project. But since Buildroot is a bundle
> of a build infrastructure *and* package recipes, you can't get a recent
> and modern Buildroot without getting a recent and modern user-space.
Yes, and these new packages may or may not build/work with the old
kernel (and presumably toolchain).
>> I do, it is yet another slightly different variant of the /dev
>> handling to confuse new users and complicate the build logic.
> Well, the /dev handling already has a number of different options, and
> the user must anyway understand a little bit how a Linux system is
> working to make a sensible choice between the different options. The
> default is sane, and will remain the same, so that clueless users
> continue to get the same experience/result.
Yes, but adding one more option that is only a slight variant of one of
them doesn't help.
When would we remove this option again? When 2.6.32 comes 10 years old?
15?
>> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
>> either.
> If it "isn't non trivial", then it is trivial, right ? :-)
Argh, the 'non' shouldn't have been there ;)
>> What I meant is actually if this option is only useful for the (few?)
>> Buildroot users with <2.6.32 kernels that want mdev support, or also for
>> others?
> Yes, it is probably only for people using kernels older than 2.6.32 who
> need mdev for automatic module loading, or firmware loading.
And we expect that to be a significant amount of people?
> There might be more users of such a thing that there are users of some
> of our weird packages. Admitted, a package is just a package and
> doesn't add any complexity to the core. But the additional complexity
> brought by Luca's work is relatively small. And his work has in fact
> uncovered a few issues in our existing code (the fact that we redirect
> the output of all inittab commands to /dev/null, and that some of them
> are in fact failing without us noticing).
Packages indeed very rarely add complexity elsewhere. And yes, reviewing
the finer inittab details is indeed good.
>> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
>> kernel. To me it looks quite self contained, so backporting it to
>> something close to 2.6.32 doesn't look too bad.
> Indeed. I wonder how many dependencies on other patches it has, though.
> Luca, can you give it a try and see if it would work for you?
From a quick look (depending on how old the kernel is) I think it is
basically just device_get_nodename():
commit 6fcf53acccf85b4b0d0260e66c692a341760f464
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Apr 30 15:23:42 2009 +0200
Driver Core: add nodename callbacks
This adds the nodename callback for struct class, struct device_type and
struct device, to allow drivers to send userspace hints on the device
name and subdirectory that should be used for it.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> I'm not sure I'm really interested in seeing a bunch of patches adding
>> 'depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_2_6_<old>' / comments to
>> packages.
> Right, this I understand. We could keep the current state of things:
> dependencies are only for >= 3.x kernels. So if something builds with
> 2.6.38 but not 2.6.32, then we don't care, and we make it depend on >=
> 3.x. Though I agree some people using 2.6.35 might complain, as they
> can technically build that thing.
So in other words, <3.x isn't really supported.
>> But I still need to be convinced that adding this other mdev variant is
>> the best tradeoff between:
>>
>> - Adding the patches
>>
>> - Ask people to backport devtmpfs to their kernel
>>
>> - Ask people to handle it in a post-build script
>>
>> - Ask people to add a initramfs mounting a tmpfs on /dev + mknod before
>> executing init
>>
>> - Asking people to stick with user space of the same "maturity" ;) as
>> their kernel
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.
>> If there's other people interested in this feature, then it would be
>> nice to hear from you.
> I agree getting more feedback from other potential users would be good.
> However, I fear that many of the people who are stuck with old crappy
> kernels are also in companies that are not necessarily very open, and
> we may simply never hear from them.
> So, as suggested above, Luca, can you try to backport devtmpfs? If that
> solves the problem, then it's probably a good enough solution.
Or alternatively, one of the other options suggested above.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 12:01 ` Peter Korsgaard
@ 2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 12:32 ` Peter Korsgaard
2015-09-15 13:03 ` Thomas Petazzoni
2015-09-15 22:34 ` Luca Ceresoli
2015-10-01 9:36 ` Luca Ceresoli
2 siblings, 2 replies; 49+ messages in thread
From: Arnout Vandecappelle @ 2015-09-15 12:27 UTC (permalink / raw)
To: buildroot
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 ]
Regards,
Arnout
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
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
1 sibling, 1 reply; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-15 12:32 UTC (permalink / raw)
To: buildroot
>>>>> "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.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 12:32 ` Peter Korsgaard
@ 2015-09-15 13:03 ` Thomas Petazzoni
2015-09-15 13:14 ` Peter Korsgaard
1 sibling, 1 reply; 49+ messages in thread
From: Thomas Petazzoni @ 2015-09-15 13:03 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Tue, 15 Sep 2015 14:27:08 +0200, Arnout Vandecappelle wrote:
>
>
> 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 ]
But then, who creates /dev/console when devtmpfs is not available? We
have it unconditionally?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 13:03 ` Thomas Petazzoni
@ 2015-09-15 13:14 ` Peter Korsgaard
0 siblings, 0 replies; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-15 13:14 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> But then, who creates /dev/console when devtmpfs is not available? We
> have it unconditionally?
I would say so, especially as we also "need" it for initramfs.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 20:19 ` Arnout Vandecappelle
@ 2015-09-15 22:07 ` Luca Ceresoli
0 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-15 22:07 UTC (permalink / raw)
To: buildroot
Dear Arnout, Thomas,
Arnout Vandecappelle wrote:
>
>
> On 14-09-15 21:34, Thomas Petazzoni wrote:
>> Dear Luca Ceresoli,
>>
>> On Mon, 14 Sep 2015 18:05:52 +0200, Luca Ceresoli wrote:
>>
>>> But now I removed that patch, and replaced with a different
>>> implementation based on Arnout's suggestion of using BUSYBOX_DEVICES.
>>
>> I am not sure using BUSYBOX_DEVICES is fully correct. The reason
>> why /dev/console is needed is *not* because of Busybox, but because of
>> the kernel that is opening /dev/console before handing control over
>> to the init application:
>>
>> http://lxr.free-electrons.com/source/init/main.c#L1011
>>
>> If you do BUSYBOX_DEVICES with just /dev/console, then you will also
>> need a SYSVINIT_DEVICES with just /dev/console.
>>
>> Though I admit my comment here is mainly nitpicking :)
>
> But of course you are right. This is part of the system/skeleton handling, and
> now skeleton is a package, we can make it part of SKELETON_DEVICES.
Aah, yes, indeed! Thanks both.
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 8:09 ` Peter Korsgaard
2015-09-15 9:41 ` Thomas Petazzoni
@ 2015-09-15 22:31 ` Luca Ceresoli
2015-09-16 7:32 ` Peter Korsgaard
1 sibling, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-15 22:31 UTC (permalink / raw)
To: buildroot
Dear Peter, Thomas,
Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
> >> Yes, but I still question the need for all of this work in the first
> >> place.
>
> > On my side, I don't. Some people are still forced to use 2.6.x kernels
> > older than 2.6.32, and if Luca (who is a knowledgeable and
> > skilled developer) has such a need, I'm sure it means there is a silent
> > group of people stuck with prehistoric kernels that would benefit from
> > this.
>
> Sure, I get that. I just question the sensibility of combining a 6+ year
> old kernel with modern user space.
I agree with you on the principle, but in the practice I have devices
running very fine on 2.6.30 and some user space applications using
C++11. Yes, I used a fairly recent toolchain (gcc 4.8 IIRC), which is
of course a bad idea, I know... But in the practice it works. I had to
spend a little time to check some packages that try to use kernel
features not available in the running kernel. IIRC I only had issues
with dhcpcd which tends to use recently-introduced syscalls. Other
packaged run without problems.
>
>
> > In addition, the changes that Luca is proposing are very
> > self-contained, and often shared with the other /dev management
> > solutions. So I don't see a lot of additional complexity in what Luca
> > is proposing.
>
> I do, it is yet another slightly different variant of the /dev
> handling to confuse new users and complicate the build logic.
>
> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
> either.
FWIW, it's even less complex in the v2 patchset that's half-brewed here.
> > I'm not sure how complicated it is to backport devtmpfs. However I
> > would suspect that it isn't that easy.
>
> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
> kernel. To me it looks quite self contained, so backporting it to
> something close to 2.6.32 doesn't look too bad.
I think I had a look a couple of years ago when I did the first project
on the same SoC. I think I had a look and found it non trival, but the
product to create had no hotplugging capabilities and no firmware
loading needs, so I just went for a static /dev.
Now I have a real goal, so I might try harder to look into backporting
devtmpfs.
> > So far, Luca has provided some patches that are perfectly documented,
> > along with test cases and test scripts to validate the booting with
> > all possible /dev management situations. To me, the perfectness of
> > Luca's contribution is a good enough argument to merge this feature
> > :-)
>
> I agree, the patches themselves are very nice work!
Thanks both! :)
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
@ 2015-09-15 22:34 ` Luca Ceresoli
2015-10-01 9:36 ` Luca Ceresoli
2 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-15 22:34 UTC (permalink / raw)
To: buildroot
Dear Peter,
Peter Korsgaard wrote:
> >> But I still need to be convinced that adding this other mdev variant is
> >> the best tradeoff between:
> >>
> >> - Adding the patches
> >>
> >> - Ask people to backport devtmpfs to their kernel
> >>
> >> - Ask people to handle it in a post-build script
> >>
> >> - Ask people to add a initramfs mounting a tmpfs on /dev + mknod before
> >> executing init
> >>
> >> - Asking people to stick with user space of the same "maturity" ;) as
> >> their kernel
>
> 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.
Indeed another interesting option. I'll consider it, thanks.
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-14 22:23 ` Arnout Vandecappelle
@ 2015-09-15 22:35 ` Luca Ceresoli
0 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-15 22:35 UTC (permalink / raw)
To: buildroot
Dear Arnout,
Arnout Vandecappelle wrote:
> On 14-09-15 15:47, Luca Ceresoli wrote:
>> Dear Thomas,
>>
>> Thomas Petazzoni wrote:
>>> Dear Luca Ceresoli,
>>>
>>> On Wed, 9 Sep 2015 14:29:36 +0200, Luca Ceresoli wrote:
> [snip]
>>>> 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.
>
> mdev doesn't but any script it calls might.
Good point. S02mdev then (if the current implementation idea will
survive at all, given the rest of the discussion).
>
> Also, if a crash happens during mdev coldplugging, it's an advantage if the
> kernel messages can be captured by syslog.
>
> So I'd prefer to keep syslog before mdev.
>
> FYI: systemd starts journald and udev in parallel (at least as far as I can
> make out from the service files).
>
> Regards,
> Arnout
>
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 22:31 ` Luca Ceresoli
@ 2015-09-16 7:32 ` Peter Korsgaard
2015-09-18 15:47 ` Luca Ceresoli
0 siblings, 1 reply; 49+ messages in thread
From: Peter Korsgaard @ 2015-09-16 7:32 UTC (permalink / raw)
To: buildroot
>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
Hi,
>> Sure, I get that. I just question the sensibility of combining a 6+ year
>> old kernel with modern user space.
> I agree with you on the principle, but in the practice I have devices
> running very fine on 2.6.30 and some user space applications using
> C++11.
Ok, and are you actively doing system level development, or "just"
adjusting a single application on a mature product? E.G. are you
interested in getting the latest versions of all the libraries or rather
freeze the entire system except for your application?
> Yes, I used a fairly recent toolchain (gcc 4.8 IIRC), which is
> of course a bad idea, I know... But in the practice it works.
Then you presumably already had to backport kernel fixes to build with
4.8? E.G. I've worked on a system stuck on 2.6.37 where I had to
backport this to get it to run with gcc 4.7+:
commit 8428e84d42179c2a00f5f6450866e70d802d1d05
Author: Catalin Marinas <catalin.marinas@arm.com>
Date: Mon Nov 7 18:05:53 2011 +0100
ARM: 7150/1: Allow kernel unaligned accesses on ARMv6+ processors
Recent gcc versions generate unaligned accesses by default on ARMv6 and
later processors. This patch ensures that the SCTLR.A bit is always
cleared on such processors to avoid kernel traping before
alignment_init() is called.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: John Linn <John.Linn@xilinx.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable at vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> I had to spend a little time to check some packages that try to use
> kernel features not available in the running kernel. IIRC I only had
> issues with dhcpcd which tends to use recently-introduced
> syscalls. Other packaged run without problems.
I've personally had issues with network-manager (and dhcpcd like you
said) as well.
>> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
>> either.
> FWIW, it's even less complex in the v2 patchset that's half-brewed here.
True.
>> > I'm not sure how complicated it is to backport devtmpfs. However I
>> > would suspect that it isn't that easy.
>>
>> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
>> kernel. To me it looks quite self contained, so backporting it to
>> something close to 2.6.32 doesn't look too bad.
> I think I had a look a couple of years ago when I did the first project
> on the same SoC. I think I had a look and found it non trival, but the
> product to create had no hotplugging capabilities and no firmware
> loading needs, so I just went for a static /dev.
> Now I have a real goal, so I might try harder to look into backporting
> devtmpfs.
It seems doable to backport devtmpfs support to 2.6.30.
I just tried cherry-picking 6fcf53acccf85b4 + 2b2af54a5bb6f7e80ccf7 and
I only get a trivial conflict about some header files getting added to
init/main.c
To give it a quick test I tweaked our qemu_x86_defconfig to build 2.6.30
+ the two backports and booted it:
Welcome to Buildroot
buildroot login: root
# uname -a
Linux buildroot 2.6.30-00193-g9a8d49a #3 Wed Sep 16 09:27:23 CEST 2015 i686 GNU/Linux
# grep devtmpfs /proc/mounts
devtmpfs /dev devtmpfs rw,size=63272k,nr_inodes=15818 0 0
(I did have to fix the kernel a bit to get it to build with sourcery
codebench 2011.09, E.G. gcc 4.6.1 - But that was just s/-m elf_x86/-m32/)
>> I agree, the patches themselves are very nice work!
> Thanks both! :)
You're welcome.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-16 7:32 ` Peter Korsgaard
@ 2015-09-18 15:47 ` Luca Ceresoli
0 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-18 15:47 UTC (permalink / raw)
To: buildroot
Dear Peter,
Peter Korsgaard wrote:
>>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
>
> Hi,
>
> >> Sure, I get that. I just question the sensibility of combining a 6+ year
> >> old kernel with modern user space.
>
> > I agree with you on the principle, but in the practice I have devices
> > running very fine on 2.6.30 and some user space applications using
> > C++11.
>
> Ok, and are you actively doing system level development, or "just"
> adjusting a single application on a mature product? E.G. are you
> interested in getting the latest versions of all the libraries or rather
> freeze the entire system except for your application?
I work both on new products and on mature products. But the latter
receive consistent updates at times, which might add a lot more packages
or change the dependencies.
In both cases I want a recent a fairly recent set of packages.
A few months ago I had to bump a library to a version that was not yet
stable at that time, and thus not yet in Buildroot, because it
implemented a method that we needed in an application.
> > Yes, I used a fairly recent toolchain (gcc 4.8 IIRC), which is
> > of course a bad idea, I know... But in the practice it works.
>
> Then you presumably already had to backport kernel fixes to build with
> 4.8? E.G. I've worked on a system stuck on 2.6.37 where I had to
> backport this to get it to run with gcc 4.7+:
Nope. Maybe because I'm currently working mostly on ARM9 machines, and
ARM9 is definitely "mature".
However I had to forced an "old" Sourcery toolchain (2013.05) for an
ARM9 project because I was getting mysterious runtime errors with
2014.05, the latest available in BR at that time.
>>>> I'm not sure how complicated it is to backport devtmpfs. However I
> >> > would suspect that it isn't that easy.
> >>
> >> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
> >> kernel. To me it looks quite self contained, so backporting it to
> >> something close to 2.6.32 doesn't look too bad.
>
> > I think I had a look a couple of years ago when I did the first project
> > on the same SoC. I think I had a look and found it non trival, but the
> > product to create had no hotplugging capabilities and no firmware
> > loading needs, so I just went for a static /dev.
>
> > Now I have a real goal, so I might try harder to look into backporting
> > devtmpfs.
>
> It seems doable to backport devtmpfs support to 2.6.30.
>
> I just tried cherry-picking 6fcf53acccf85b4 + 2b2af54a5bb6f7e80ccf7 and
> I only get a trivial conflict about some header files getting added to
> init/main.c
>
> To give it a quick test I tweaked our qemu_x86_defconfig to build 2.6.30
> + the two backports and booted it:
>
> Welcome to Buildroot
> buildroot login: root
> # uname -a
> Linux buildroot 2.6.30-00193-g9a8d49a #3 Wed Sep 16 09:27:23 CEST 2015 i686 GNU/Linux
> # grep devtmpfs /proc/mounts
> devtmpfs /dev devtmpfs rw,size=63272k,nr_inodes=15818 0 0
>
> (I did have to fix the kernel a bit to get it to build with sourcery
> codebench 2011.09, E.G. gcc 4.6.1 - But that was just s/-m elf_x86/-m32/)
Interesting. I'll have a look... sometime.
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 12:32 ` Peter Korsgaard
@ 2015-09-18 16:37 ` Luca Ceresoli
0 siblings, 0 replies; 49+ messages in thread
From: Luca Ceresoli @ 2015-09-18 16:37 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 22:34 ` Luca Ceresoli
@ 2015-10-01 9:36 ` Luca Ceresoli
2015-10-01 10:03 ` Peter Korsgaard
2 siblings, 1 reply; 49+ messages in thread
From: Luca Ceresoli @ 2015-10-01 9:36 UTC (permalink / raw)
To: buildroot
Dear Peter,
Peter Korsgaard wrote:
[...]
> >> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
> >> kernel. To me it looks quite self contained, so backporting it to
> >> something close to 2.6.32 doesn't look too bad.
>
> > Indeed. I wonder how many dependencies on other patches it has, though.
> > Luca, can you give it a try and see if it would work for you?
>
> From a quick look (depending on how old the kernel is) I think it is
> basically just device_get_nodename():
>
> commit 6fcf53acccf85b4b0d0260e66c692a341760f464
> Author: Kay Sievers <kay.sievers@vrfy.org>
> Date: Thu Apr 30 15:23:42 2009 +0200
>
> Driver Core: add nodename callbacks
>
> This adds the nodename callback for struct class, struct device_type and
> struct device, to allow drivers to send userspace hints on the device
> name and subdirectory that should be used for it.
>
> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
> Signed-off-by: Jan Blunck <jblunck@suse.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wow, it works! Well, at least it boots, I haven't tested everything,
but it was far simpler that I suspected. Thanks for the hint!
--
Luca
^ permalink raw reply [flat|nested] 49+ messages in thread
* [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
2015-10-01 9:36 ` Luca Ceresoli
@ 2015-10-01 10:03 ` Peter Korsgaard
0 siblings, 0 replies; 49+ messages in thread
From: Peter Korsgaard @ 2015-10-01 10:03 UTC (permalink / raw)
To: buildroot
>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
Hi,
>> This adds the nodename callback for struct class, struct device_type and
>> struct device, to allow drivers to send userspace hints on the device
>> name and subdirectory that should be used for it.
>>
>> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
>> Signed-off-by: Jan Blunck <jblunck@suse.de>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Wow, it works! Well, at least it boots, I haven't tested everything,
> but it was far simpler that I suspected. Thanks for the hint!
Wee, that's good to hear!
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2015-10-01 10:03 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.