public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Mike Bell <kernel@mikebell.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: devfs vs udev, thoughts from a devfs user
Date: Fri, 13 Feb 2004 13:19:20 -0800	[thread overview]
Message-ID: <20040213211920.GH14048@kroah.com> (raw)
In-Reply-To: <20040210182943.GO4421@tinyvaio.nome.ca>

On Tue, Feb 10, 2004 at 10:29:44AM -0800, Mike Bell wrote:
> On Tue, Feb 10, 2004 at 10:12:42AM -0800, Greg KH wrote:
> > No, that is not true.  devfs exports the device node itself.  It does
> > not just export the major:minor number.
> 
> That's a pretty minor difference, from the kernel's point of view. It's
> basically putting the same numbers in different fields.

Heh, that's a HUGE difference!

I think you are missing a few things here:
  - sysfs is not only for exporting device major:minor info.  It's for a
    1001 other very useful things.  You can't config out sysfs, you get
    it for "free" with 2.6.  So it isn't a "choose sysfs vs. devfs"
    argument at all.  It's a "do I want to enable devfs or not" issue.
  
 - sysfs exports loads of info about every device in your system, not
   only the major:minor info.  It exports what device this major:minor
   is assigned to, the topology of the device, the fact that it has
   vendor id FOO and product id BAR, and serial number "123".  devfs has
   none of this.

 - you get /sbin/hotplug calls for "free" too.  Yes, you can config this
   out, but the added benefits of hotplug calls far outweigh any memory
   savings you get for not enabling this option (embedded systems not
   included.)

So, if you put hotplug and sysfs together, udev can control your /dev.
And it can provide persistent device naming, which on its own, devfs can
not.

Again, the fact that udev can do everything devfs can (manage a /dev),
in userspace, and in less memory, is a big win in my eyes.

Oh, and recall that I implemented a "dynamic /dev" with LSB names almost
a year ago, in 6Kb of userspace code.  The amount of memory that this
takes for devfs to do I don't really want to imagine...

> > devfs also does not export the position within the entire device tree,
> > which sysfs does.  
> 
> devfs tried to do just that. sysfs does it better though. I don't see
> what that has to do with my point.

persistent device names...  That's the main point of udev.

> > They are two completely different filesystems, doing two completely
> > different things.  Please do not confuse them.
> 
> sysfs and devfs are very different. I said they both accomplish one
> common goal, sysfs for udev and devfs for devfsd.

Not at all.  sysfs has 1001 goals at the least.  So many different
people are using it for different things that it's really amazing to me.
It also shows how powerful and how correct the model of it is.

And as stated above, you always get sysfs in your kernel (unless you are
running the -tiny tree...)

I'm not going to try to answer all of your other questions specifically,
as I think I have covered them all now.  If you feel that you still have
some questions remaining about this, or that I have not explained
anything good enough, please let me know.

thanks,

greg k-h

  parent reply	other threads:[~2004-02-13 21:22 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-10 11:34 devfs vs udev, thoughts from a devfs user 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 [this message]
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
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
  -- strict thread matches above, loose matches on Subject: below --
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=20040213211920.GH14048@kroah.com \
    --to=greg@kroah.com \
    --cc=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