Create /dev/null along with /dev/console when building cpio rootfs
PATCH 1/1 Create /dev/null along with /dev/console when building cpio rootfs
I am currently forced to support an older kernel (2.6.18). That kernel does not have devtmpfs support. However, I'd still like to be able to use mdev for automatic /dev management. mdev seems to be more than happy to work on top of just plain tmpfs (well, technically, in my case it is the special rootfs instance of tmpfs). However, init is unhappy because /dev/null hasn't been created by the time init runs. This patch creates /dev/null in addition to /dev/console when building the cpio rootfs, so that /dev/null will be there when init runs. Afterward, mdev is able to take care of the rest.
Dan Moulding (1):
Create /dev/null device node when building a cpio rootfs
fs/cpio/cpio.mk | 1 + 1 file changed, 1 insertion(+)
Signature · 1 line
1.8.2.1
PATCH 1/1 Create /dev/null device node when building a cpio rootfs
This allows mdev to be used for automatic device creation, even if the kernel doesn't support devtmpfs. The programs that run before mdev (e.g. init) expect /dev/null to already exist.
--- fs/cpio/cpio.mk | 1 + 1 file changed, 1 insertion(+)
fs/cpio/cpio.mk +1 -0
@@ -22,6 +22,7 @@ define ROOTFS_CPIO_ADD_INIT endef PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep) +PACKAGES_PERMISSIONS_TABLE += /dev/null c 666 0 0 1 3 - - -$(sep) endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
Signature · 1 line
1.8.2.1
PATCH 1/1 Create /dev/null device node when building a cpio rootfs
Quoted 14 lines · Dan Moulding
This allows mdev to be used for automatic device creation, even if the kernel doesn't support devtmpfs. The programs that run before mdev (e.g. init) expect
/dev/nullto already exist.Signed-off-by Dan Moulding <[email protected]>--- fs/cpio/cpio.mk | 1 + 1 file changed, 1 insertion(+)fs/cpio/cpio.mk +0
-0
fs/cpio/cpio.mk define ROOTFS_CPIO_ADD_INIT · line 25
Quoted 4 lines
fs/cpio/cpio.mk +1
-0@@ -22,6 +22,7 @@ define ROOTFS_CPIO_ADD_INIT endef PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep) +PACKAGES_PERMISSIONS_TABLE += /dev/null c 666 0 0 1 3 - - -$(sep)
How is this issue limited to the cpio rootfs? You'll have the same issue
with any rootfs, right?
So perhaps a better solution is to move /dev/console and /dev/null from
device_table_dev.txt to device_table.txt.
Quoted 33 lines · Thomas Petazzoni
fs/cpio/cpio.mk +0
-0Le Tue, 13 Dec 2011 09:39:34 +0100,Arnout Vandecappelle <[email protected]> a ?crit :
Quoted 4 lines
If you ask me, it's OK to add /dev entries in the
BR2_ROOTFS_DEVICE_TABLE. In fact, I think/dev/consoleand/dev/nullshould be put in there. But I've never gotten around to roll a patch for it.FWIW, when I initially introduced (based on prior patches) this static /dev vs. devtmpfs vs. mdev vs. udev selection, the mdev and udev choices were independent of devtmpfs, i.e there were using a minimal device tables with
/dev/nulland/dev/console. But after discussion on the mailing-list, it was decided that it was better to make devtmpfs a requirement when mdev and udev were choosen.See
Message-Id: <f92465f9de8bcd24cf2c974b158a600a84e96422.1291582352.git.thomas.petazzoni@free-electrons.com>
for the initial patch I proposed on December, 5th 2010.
And
Message-ID: <[email protected]>
for Peter's answer (December, 17th 2010), saying :
"""
Thomas> At compile time, only a minimal /dev is created in the filesystem, Thomas> with only "console" and "null". This is done thanks to a small device Thomas> table intarget/generic/device_table_mdev_udev.txt. This is done Thomas> directly at the configuration level (fs/Config.in).
Quoted 5 lines
While I agree we need the minimal device table for
/etc/shadowand similar permissions, do we really need to support mdev/udev without devtmpfs? It's been in the kernel now for close to 2 years, it's very small and it simplifies (and speeds up) the boot sequence quite a lot. """
IOW this approach was suggested before but not really picked up.
Note that if we do that, we can revert e1ebae70 and perhaps even10a130f9. Actually, 10a130f9 can probably already be reverted, since e1ebae70 should have the same effect.
Regards,
Arnout
Quoted 4 lines
endif #
BR2_ROOTFS_DEVICE_CREATION_STATIC
Signature · 6 lines
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 Create /dev/null device node when building a cpio rootfs
Quoted 3 lines · Arnout Vandecappelle
How is this issue limited to the cpio rootfs? You'll have the same issue
with any rootfs, right?
Absolutely. But it was only making /dev/console for cpio... so I decided to follow suit, thinking maybe there was a good reason for it.
Quoted 4 lines
So perhaps a better solution is to move
/dev/consoleand/dev/nullfrom
device_table_dev.txt to device_table.txt.
Agreed.
Quoted 2 lines
IOW this approach was suggested before but not really picked up.
Yes. And in fact, I had stumbled upon these past discussions when Googling about this. I just wasn't sure why it never got picked up.
Cheers,
-- Dan
PATCH 1/1 Create /dev/null device node when building a cpio rootfs
In reply to Arnout VandecappelleDear Arnout Vandecappelle,
Quoted 7 lines · Arnout Vandecappelle
Quoted 7 lines
fs/cpio/cpio.mk +0
-0@@ -22,6 +22,7 @@ define ROOTFS_CPIO_ADD_INIT endef
Quoted 5 lines
fs/cpio/cpio.mk define ROOTFS_CPIO_ADD_INIT · line 25
Quoted 2 lines
fs/cpio/cpio.mk +1
-0PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep) +PACKAGES_PERMISSIONS_TABLE += /dev/null c 666 0 0 1 3 - - -$(sep)How is this issue limited to the cpio rootfs? You'll have the same issue
with any rootfs, right?
Yes. The mdev support makes the assumption that devtmpfs support is available in the kernel.
Quoted 2 lines
So perhaps a better solution is to move
/dev/consoleand/dev/nullfrom
device_table_dev.txt to device_table.txt.
Not really:
* In the initramfs case, /dev/console is needed. For static /dev, it's already there. For non-static /dev, we have to have a static /dev/console until our init script mounts devtmpfs. So it's really an initramfs specific issue.
* For the non-initramfs case. For static /dev, it's already there. For non-static /dev, devtmpfs is mounted *before* init is started, so /dev/console is also already there.
Quoted 3 lines
Note that if we do that, we can revert
e1ebae70and perhaps even10a130f9. Actually,10a130f9can probably already be reverted, sincee1ebae70should have the same effect.
I agree. Would you mind sending a patch reverting 10a130f9 ?
Also, since we seem to agree that the patch proposed by Dan was not needed, I've marked http://patchwork.ozlabs.org/patch/343880/ as Rejected in our patch tracking system.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com