From: Olivier Mehani <shtrom@ssji.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: devfs gone, and now?
Date: Sat, 26 Jun 2004 13:48:38 +0000 [thread overview]
Message-ID: <20040626154838.58a46353.shtrom@ssji.net> (raw)
In-Reply-To: <Pine.LNX.4.53.0406260838290.12525@yvahk01.tjqt.qr>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
On Sat, 26 Jun 2004 08:41:10 +0200 (MEST)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> devfs is tagged obsolete and I'm worrying about what modules will now
> do, because with devfs they could create a node in /dev whenever they
> were loaded, and remove that, if unloaded. That's now missing, or is
> there an udev solution?
udev is there to replace, in userland, the behavior devfs had in
kernelspace
> As I currently see it, udev creates a "static" device node in /dev
> which persists even across reboots, so if you load a lot of modules
> which create a lot of block/char/etc. devices in /dev, they would
> probably be removed upon'rmmod', but not if you just reboot.
in fact, it creates a static node, but in a tmpfs /dev (if you use the
udevstart script), which does _not_ persist across reboots
the mechanism now (please correct me if this is not totally true) is :
1. a device is plugged in or discovered, the kernel generates an event
2. hotplug handles this event and loads the appropriate driver
3. the driver tells the kernel something like "i manage a device called
/dev/foo"
4. hotplug then calls udev with this information
5. udev applies the different rules to create the needed device nodes
and calls every user supplied script to execute any type of operation
after the node has been created (like mounting a filesystem,...)
when a device is removed, another event is generated, the process is
globally the same, but ends up with udev removing the (now useless)
nodes, so everything is okay
of course, udev will only remove nodes it created, so if you start with
your old /dev, nothing new will happen, but, once the udevstart script
has been executed, you'll get something much like devfs regarding the
number of present nodes
note: it may however be interesting to have a static /dev on your root
filesystem, just in case something went wrong and you had to boot your
system without starting udev
--
Olivier Mehani <shtrom@ssji.net>
PGP fingerprint = 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-06-26 13:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-26 6:41 devfs gone, and now? Jan Engelhardt
2004-06-26 13:26 ` Kevin P. Fleming
2004-06-26 13:48 ` Olivier Mehani [this message]
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=20040626154838.58a46353.shtrom@ssji.net \
--to=shtrom@ssji.net \
--cc=linux-hotplug@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).