From: Ed Sweetman <ed.sweetman@wmich.edu>
To: greg@kroah.com
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: devfs to be obsloted by udev?
Date: Tue, 02 Sep 2003 10:09:48 -0400 [thread overview]
Message-ID: <3F54A4AC.1020709@wmich.edu> (raw)
It appears that devfs is to be replaced by the use of udev in the not so
distant future. I'm not sure how it's supposed to replace a static /dev
situaton seeing as how it is a userspace daemon. Is it not supposed to
replace /dev even when it's completed? I dont see the real benefit in
having two directories that basically give the same info. Right now we
have something like that with proc and sysfs although not everything in
proc makes sense to be in sysfs and both are virtual fs's where as /dev
is a static fs on the disk that takes up space and inodes and includes
way too many files that a system may not use. If udev is to take over
the job of devfs, how will modules and drivers work that require device
files to be present in order to work since undoubtedly the udev daemon
will have to wait until the kernel is done booting before being run.
I'm just not following how it is going to replace devfs and thus why
devfs is being abandoned as mentioned in akpm's patchset. Or as it
seems, already has been abandoned.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It appears that devfs is to be replaced by the use of udev in the not so
distant future. I'm not sure how it's supposed to replace a static /dev
situaton seeing as how it is a userspace daemon. Is it not supposed to
replace /dev even when it's completed? I dont see the real benefit in
having two directories that basically give the same info. Right now we
have something like that with proc and sysfs although not everything in
proc makes sense to be in sysfs and both are virtual fs's where as /dev
is a static fs on the disk that takes up space and inodes and includes
way too many files that a system may not use. If udev is to take over
the job of devfs, how will modules and drivers work that require device
files to be present in order to work since undoubtedly the udev daemon
will have to wait until the kernel is done booting before being run.
I'm just not following how it is going to replace devfs and thus why
devfs is being abandoned as mentioned in akpm's patchset. Or as it
seems, already has been abandoned.
next reply other threads:[~2003-09-02 18:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-02 14:09 Ed Sweetman [this message]
2003-09-02 18:20 ` devfs to be obsloted by udev? Greg KH
2003-09-02 14:32 ` Ed Sweetman
2003-09-02 18:44 ` Greg KH
2003-09-02 23:56 ` Kurt Wall
2003-09-02 20:19 ` Bartlomiej Zolnierkiewicz
2003-09-03 9:38 ` Justin Cormack
2003-09-03 18:41 ` Greg KH
2003-09-03 19:06 ` Bryan O'Sullivan
2003-09-03 19:17 ` Sam Ravnborg
2003-09-03 21:09 ` Bryan O'Sullivan
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=3F54A4AC.1020709@wmich.edu \
--to=ed.sweetman@wmich.edu \
--cc=greg@kroah.com \
--cc=linux-kernel@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