All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael S. Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] Question about using mdev for /dev management
Date: Tue, 13 Dec 2011 08:58:08 -0600	[thread overview]
Message-ID: <201112130858.10405.minimod@morethan.org> (raw)
In-Reply-To: <201112130939.34100.arnout@mind.be>

On Tue December 13 2011, Arnout Vandecappelle wrote:
> 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...
>

It does, and it has for nearly a decade.  ;-)

With tmpfs sysfs available in the kernel and a tmpfs mounted on /dev -
an mdev -s will populate it for you.

It was only recent changes to the BR configuration dependences that make
(when looking at the BR menu) that mdev/udev requires devtmpfs.

That was just a decision by the project to move forward with the new
and drop the old but it isn't dropped in the kernel. ;-)

Mike
> 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
> 

  parent reply	other threads:[~2011-12-13 14:58 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
2011-12-13 13:39   ` Thomas Petazzoni
2011-12-13 14:58   ` Michael S. Zick [this message]
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=201112130858.10405.minimod@morethan.org \
    --to=minimod@morethan.org \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

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

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