From: Mike Bell <kernel@mikebell.org>
To: linux-kernel@vger.kernel.org
Subject: Re: devfs vs udev, thoughts from a devfs user
Date: Tue, 10 Feb 2004 10:43:03 -0800 [thread overview]
Message-ID: <20040210184302.GP4421@tinyvaio.nome.ca> (raw)
In-Reply-To: <20040210181932.GI28111@kroah.com>
On Tue, Feb 10, 2004 at 10:19:32AM -0800, Greg KH wrote:
> But devfs never used the dynamic major/minor code. No one used it.
> It's not even present anymore in 2.6. That shows that devfs does not
> solve this problem by itself.
Does udev solve this problem by itself? :) No, it is just agnostic to
the change being made in the kernel. Pretty much the same way devfsd
would be.
> Heh, you haven't ever converted a driver to use devfs have you? If so,
> you would have seen the fact that you had to specify your devfs name in
> the driver interface. That's hard coding the naming scheme in the
> kernel.
It's hard coding _a_ name in the kernel. And what's bad about having a
constant name for the device, if the user can have their own alternate
names? If you ask me, that's many times BETTER than having every
system use totally different names for every device with no way to
predictably find a device by name. At least with devfs I know that
/dev/input/mice will be named /dev/input/mice. This "no policy in kernel
space" you claim as a benefit really amounts to "/dev/input/mice could
be named anything at all". The default config may have a predictable LSB
type name, but what you're talking about isn't the flexibility to have
it named anything you want, but the flexibility NOT to have an
alternate, predictable name as well. Why is that a good thing?
> And how flexible does devfsd allow you to specify your own naming
> scheme? How can you get the info from devfsd that you need to provide a
> proper device name? No one I know has ever does this. And I know some
> people who tried real hard...
That's a valid point against the existing devfs/devfsd, there are a few
of those (the races, for instance). But it's not inherent to the idea of
a devfs.
> udev defaults to this. Which is the sane thing to do.
I don't know about that. from what I remember of the original devfs
discussion, it was along the lines of "LSB involves every device in
/dev, and is dumb. We need a new scheme, this is as good as any. Anyone
who has a better idea for how devices should be laid out, let me know."
next prev parent reply other threads:[~2004-02-10 18:44 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-10 11:34 Mike Bell
2004-02-10 13:20 ` Helge Hafting
2004-02-10 14:46 ` Mike Bell
2004-02-10 17:02 ` Mark Mielke
[not found] ` <20040210160011.GJ4421@tinyvaio.nome.ca>
2004-02-11 9:44 ` Helge Hafting
2004-02-11 20:05 ` Theodore Ts'o
2004-02-10 13:32 ` Ian Kent
2004-02-10 14:00 ` Mike Bell
2004-02-10 17:01 ` Greg KH
2004-02-10 17:13 ` Mike Bell
2004-02-10 17:25 ` Greg KH
2004-02-10 17:46 ` Mike Bell
2004-02-10 18:12 ` Greg KH
2004-02-10 18:29 ` Mike Bell
2004-02-10 22:19 ` Matthew Reppert
2004-02-11 1:10 ` Mike Bell
2004-02-11 10:05 ` Helge Hafting
2004-02-13 21:19 ` Greg KH
2004-02-14 8:51 ` Mike Bell
2004-02-14 9:13 ` Christian Borntraeger
2004-02-14 11:42 ` Helge Hafting
2004-02-14 16:54 ` Greg KH
2004-02-14 17:44 ` Alex Goddard
2004-02-15 8:16 ` Andrew Walrond
2004-02-19 9:47 ` Mike Bell
2004-02-19 19:43 ` Greg KH
2004-02-27 0:02 ` Mike Bell
2004-02-10 19:10 ` Shawn
2004-02-10 17:52 ` Chris Friesen
2004-02-10 19:24 ` Mike Bell
2004-02-10 19:46 ` Chris Friesen
2004-02-10 19:58 ` Tomasz Torcz
2004-02-10 20:11 ` Kevin P. Fleming
2004-02-10 20:39 ` Bill Rugolsky Jr.
2004-02-11 1:16 ` Greg KH
2004-02-11 1:41 ` Kevin P. Fleming
2004-02-11 9:36 ` Maneesh Soni
2004-02-11 7:50 ` viro
2004-02-11 12:33 ` Bill Rugolsky Jr.
2004-02-11 15:11 ` [PATCH] Fix /etc/mtab updating with mount --move [was Re: devfs vs udev, thoughts from a devfs user] Bill Rugolsky Jr.
2004-02-11 19:19 ` devfs vs udev, thoughts from a devfs user dleonard
2004-02-10 20:32 ` Diego Calleja García
2004-02-11 1:20 ` Mike Bell
2004-02-10 20:15 ` Timothy Miller
2004-02-10 22:24 ` Matthew Reppert
2004-02-11 1:35 ` Mike Bell
2004-02-10 20:44 ` Valdis.Kletnieks
2004-02-10 17:55 ` Mike Bell
2004-02-10 18:19 ` Greg KH
2004-02-10 18:43 ` Mike Bell [this message]
2004-02-10 20:11 ` Theodore Ts'o
2004-02-11 1:49 ` Mike Bell
2004-02-10 19:12 ` Mike Bell
2004-02-13 21:08 ` Greg KH
2004-02-10 18:35 ` Greg KH
2004-02-11 1:25 ` Ian Kent
2004-02-10 16:10 "Andrey Borzenkov"
[not found] <fa.i9mtr77.1pja9qf@ifi.uio.no>
[not found] ` <fa.de6p9mb.1ikipbl@ifi.uio.no>
2004-02-13 22:08 ` walt
2004-02-13 22:18 ` Greg KH
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=20040210184302.GP4421@tinyvaio.nome.ca \
--to=kernel@mikebell.org \
--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
all inboxes | Powered by JetHome®