From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] editing device_table_dev.txt
Date: Sun, 24 Feb 2013 18:26:20 +0100 [thread overview]
Message-ID: <20130224182620.2283ceb3@skate> (raw)
In-Reply-To: <5126AC9B.30302@mind.be>
Dear Arnout Vandecappelle,
On Fri, 22 Feb 2013 00:24:11 +0100, Arnout Vandecappelle wrote:
> > What you mean that mdev or udev does not create device nodes ???
> > If older kernels don't support devtmpfs like Baruch
> > said then who does that device node creation if not the mdev or udev
> > when event happens ???
>
> Well, nobody...
>
> Turns out that mdev still does device node creation. Makes me
> wonder if I'm not mistaken about udev as well... I just remember
> hearing that device node creation was removed when DEVTMPFS was
> introduced.
Yes, I think you got the thing wrong: udev and mdev are still creating
the device nodes. Of course, they might have already been created by
devtmpfs, but I don't think it is a requirement. At least, devtmpfs is
definitely not a requirement for mdev to work (except in Buildroot, in
which we made the decision that if mdev is to be used, then devtmpfs
support must be there).
> >> That said, you can create custom mdev/udev rules to create device
> >> nodes. But it's all manual - and much simpler to just create the
> >> device nodes manually.
> >>
> >
> > for mdev it's just a single file, /etc/mdev.conf (I can even
> > copy-paste it here, it's not that long and will cover 99% of needs).
>
> Yes, but that file just specifies the chmod/chown rules, not how to
> create the device nodes. But as I just saw in the code, mdev does in
> fact create the device nodes.
udev can also create symbolic links to device files based on custom
rules, or other funky things.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-02-24 17:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 23:37 [Buildroot] editing device_table_dev.txt John Stile
2013-02-21 10:14 ` Stefan Fröberg
2013-02-21 10:21 ` Stefan Fröberg
2013-02-21 10:23 ` Baruch Siach
2013-02-21 10:32 ` Stefan Fröberg
2013-02-21 22:57 ` Arnout Vandecappelle
2013-02-21 23:07 ` Stefan Fröberg
2013-02-21 23:24 ` Arnout Vandecappelle
2013-02-21 23:32 ` Stefan Fröberg
2013-02-23 9:30 ` Arnout Vandecappelle
2013-02-23 11:18 ` Stefan Fröberg
2013-02-24 17:26 ` Thomas Petazzoni [this message]
2013-02-24 18:11 ` Peter Korsgaard
2013-02-24 17:24 ` Thomas Petazzoni
2013-02-21 23:14 ` Arnout Vandecappelle
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=20130224182620.2283ceb3@skate \
--to=thomas.petazzoni@free-electrons.com \
--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.