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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox