Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Question about using mdev for /dev management
Date: Tue, 13 Dec 2011 09:39:34 +0100	[thread overview]
Message-ID: <201112130939.34100.arnout@mind.be> (raw)
In-Reply-To: <4EDD1149.8060104@carallon.com>

On Monday 05 December 2011 19:45:29 Will Wagner wrote:
> Firstly it replaces $(TARGET_DIR)/init with fs/cpio/init which attempts 
> to mount devtmpfs. My kernel doesn't support this (it's too old) and I'd 
> rather not get this trace in the boot (it worries other developers).

 I didn't realize that mdev worked without devtmpfs in the kernel...
If devtmpfs exists (and it does for all currently supported kernels), then
it should be mounted as soon as possible.  It is normally mounted
automatically by the kernel, except when it runs /init for an initramfs.
That's why we have this extra /init script for the cpio rootfs.

 You could add a check to the init script that mounts a normal tmpfs on
/dev if the mount fails (and redirect its output to /dev/null).

> I assume that for mdev we could not replace init but instead make sure 
> that /dev/console (and possibly /dev/null?) exist?

 Yeah, actually, I think /dev/console and /dev/null should be created
on the rootfs even if devtmpfs is used.  Which brings us to:


> The other small issue I have is that mdev fails to spot one of the 
> kernel devices (as the driver doesn't have a sysfs entry) so it needs 
> adding manually. I do that by adding an entry to BR2_ROOTFS_DEVICE_TABLE 
> which works fine, but doesn't seem ideal as I thought device entries 
> were meant to be set in BR2_ROOTFS_STATIC_DEVICE_TABLE, but that is not 
> offered unless static devices used. Is there a better way to do this or 
> should I just leave it as is?

 If you ask me, it's OK to add /dev entries in the BR2_ROOTFS_DEVICE_TABLE.
In fact, I think /dev/console and /dev/null should be put in there.  But
I've never gotten around to roll a patch for it.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

  reply	other threads:[~2011-12-13  8:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 18:45 [Buildroot] Question about using mdev for /dev management Will Wagner
2011-12-13  8:39 ` Arnout Vandecappelle [this message]
2011-12-13 13:39   ` Thomas Petazzoni
2011-12-13 14:58   ` Michael S. Zick
2011-12-13 15:24   ` Michael S. Zick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201112130939.34100.arnout@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox