linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: udev and devfs - The final word
@ 2004-01-08 13:05 "Andrey Borzenkov" 
  0 siblings, 0 replies; 158+ messages in thread
From: "Andrey Borzenkov"  @ 2004-01-08 13:05 UTC (permalink / raw)
  To: "Greg KH" ; +Cc: linux-kernel

> > > 
> > >  2) We are (well, were) running out of major and minor numbers for
> > >     devices.
> > 
> > devfs tried to fix this one by _getting rid_ of those numbers.
> > Seriously - what are they needed for?  
>
> But devfs failed in this.  The devfs kernel interface still requires a
> major/minor number to create device nodes.
>
> Hopefully I can work on fixing this up in 2.7.

You must be kidding here. Where exactly do you see devfs fault?

It is not "devfs kernel interface". It is "kernel userland interface"
that requires a major/minor to associate device node with device.

Devfs (in its current shape) is no more than just a repository of
(device node, major/minor) relations. Devfs does not care where
dev number comes from. Driver may hardcode it or request
dynamically from kernel, either way is fine.

Answering your other mail - "devfs kernel interface" provided ability
to request dynamic device number when registering a node. Sounds
very much like what you'd wish. Somebody decided it was evil and
removed it. I personally do not care either way.

regards

-andrey

^ permalink raw reply	[flat|nested] 158+ messages in thread
* Re: udev and devfs - The final word
@ 2004-01-08 13:53 "Andrey Borzenkov" 
  2004-01-08 15:40 ` Ian Kent
  2004-01-09  8:51 ` Helge Hafting
  0 siblings, 2 replies; 158+ messages in thread
From: "Andrey Borzenkov"  @ 2004-01-08 13:53 UTC (permalink / raw)
  To: "Greg KH" ; +Cc: linux-kernel


> So, how does devfs stack up to the above problems and constraints:
>   Problems:
>     1) devfs only shows the dev entries for the devices in the system.

Is this a problem? Where exactly this problem lies?

>     2) devfs does not handle the need for dynamic major/minor numbers

Neither does udev. Both take whatever driver gives them.

>     3) devfs does not provide a way to name devices in a persistent
>        fashion.

I am not sure what exactly you mean here.

>     4) devfs does provide a deamon that userspace programs can hook > into
>        to listen to see what devices are being created or removed.
>   Constraints:
>     1) devfs forces the devfs naming policy into the kernel.  If you
>        don't like this naming scheme, tough.

kernel imposes naming scheme for exporting devices in sysfs. It is
possible to get rid of devfs_name in kernel and use those names
that must exist anyway to support udev as well. devfs has
devfsd that can call whatever naming agent you like.

>     2) devfs does not follow the LSB device naming standard.

it is user-space (devfsd) issue, not kernel space (devfs)

>     3) devfs is small, and embedded devices use it.  However it is
>        implemented in non-pagable memory.

Same for sysfs. Other Unices have pageable kernel memory. If Linux
had it any memory based filesystem could benefit from it. I did not
look at backing store for sysfs patches but it is likely that same
idea could be used for devfs.

> Oh yeah, and there are the insolvable race conditions with the devfs
> implementation in the kernel, but I'm not going to talk about them > right

I do not argue that current devfs implementation is ugly and racy. I
just beg you to point at what makes those races "unsolvable".

> now, sorry.  See the linux-kernel archives if you care about them (and
> if you use devfs, you should care...)

I do care. Searching archives for devfs mostly brings "everyone knows
this is crap". That is why I kindly ask you to show real evidence that
the problems it has are unsolvable.

> So devfs is 2 for 7, ignoring the kernel races.

Hmm ... I really see only one - devfs names that are historically
used. Assuming that

- devfs just exports kernel names (that must exist anyway)
- sysfs provides consistent cdev view as it does for bdev

devfsd simply can take kernel name and call whatever program you like
to implement naming policy including udev. With added benefit of
removable devices support :)

regards

-andrey

^ permalink raw reply	[flat|nested] 158+ messages in thread
* Re: udev and devfs - The final word
@ 2004-01-06  1:20 Paul Zimmerman
  0 siblings, 0 replies; 158+ messages in thread
From: Paul Zimmerman @ 2004-01-06  1:20 UTC (permalink / raw)
  To: Rob Landley; +Cc: linux-kernel

On Tuesday 06 January 2004 00:31 Rob Landley wrote:
> What about kernel upgrades?  Future backwards compatability when
developers
> change the device enumeration methods?  (The sata driver got completely
> rewritten from scratch, and now it detects devices in a wildly different
> order, but we need this shim layer for backwards compatability with a
> guarantee we never should have made because we encouraged old scripts to
> remain broken.)  This plants hidden land mines restricting future
> development.  You're basically proposing a whole "device number
stabilization
> infrastructure" for future kernels if it's to have ANY meaning at all...

Did people really write scripts that used major:minor numbers to refer to
devices? I would have thought they would use the /dev/xxx name, and those
will
not change when "random" device numbers are implemented, will they?

- Paul


^ permalink raw reply	[flat|nested] 158+ messages in thread
[parent not found: <fa.flhsork.uka2hg@ifi.uio.no>]
* Re: udev and devfs - The final word
@ 2004-01-01 16:59 Shaheed
  0 siblings, 0 replies; 158+ messages in thread
From: Shaheed @ 2004-01-01 16:59 UTC (permalink / raw)
  To: linux-kernel

Rob Landley wrote:

>Combine that with hotplug and you have a world of pain. Generating a number 
> from a device is just a fancy hashing function, but as soon as you have two 
> devices that generate the same number independently (when in separate 
> systems) and you plug them both into the same system: boom.

If one has two otherwise identical devices, the only thing that distinguishes 
them to the system is their point of attachment. Even from a user's point of 
view, the only difference is the connector it is plugged into. That implies 
that the hash resolution value ought to be based on the point of attachment.

It seems to me that the key to making this system as transparent as possible 
is to make these source value of the hash and the attachment point visible 
and navigable by userspace/humans. Perhaps something like this:

- every driver exports its name and some driver-or-devicetype-dependant value 
(serial number, MAC address, disk WWID, pty number, kernel address of kobject 
or whatever) to /sbin/hotplug. The userspace logic gets to hash+uniquify the 
value as required, and then create a sysfs tree node ("/uid/xxx") whose 
leaves contain the point of attachment.

- At the bottom of the sysfs tree for the device add a leaf that points back 
to the entry into "/uid" tree.

Thus, userspace can navigate in either direction between the point of 
attachment, and the identifiying characteristic of the deivce.

Thanks, Shaheed

^ permalink raw reply	[flat|nested] 158+ messages in thread
[parent not found: <fa.af64864.ugabhg@ifi.uio.no>]
[parent not found: <18Cz7-7Ep-7@gated-at.bofh.it>]
* udev and devfs - The final word
@ 2003-12-31  0:29 Greg KH
  2003-12-31  0:53 ` Prakash K. Cheemplavam
                   ` (3 more replies)
  0 siblings, 4 replies; 158+ messages in thread
From: Greg KH @ 2003-12-31  0:29 UTC (permalink / raw)
  To: linux-hotplug-devel, linux-kernel

(This text can be found at
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs for those who
want to link to it.  I'll also update it with info based on the thread I
know is going to spawn from this post...)


Executive summary for those too lazy to read this whole thing:
	I don't care about devfs, and I don't want to talk about it at
	all anymore.  If you love devfs, fine, I'm not trying to tell
	anyone what to do.  But you really should be looking into using
	udev instead.  All further email messages sent to me about devfs
	will be gladly ignored.


First off, some background.  For a description of udev, and what it's
original design goals were, please see the OLS 2003 paper on udev,
available at:
	<http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
and the slides for the talk, available at:
	<http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
The OLS paper can also be found in the docs/ directory of the udev
tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/
directory.

In that OLS paper, I described the current situation of a static /dev
and the current problems that a number of people have with it.  I also
detailed how devfs tries to solve a number of these problems.  In
hindsight, I should have never mentioned the word, devfs, when talking
about udev.  I did so only because it seemed like a good place to start
with.  Most people understood what devfs is, and what it does.  To
compare udev against it, showing how udev was more powerful, and a more
complete solution to the problems people were having, seemed like a
natural comparison to me.

But no more.  I hereby never want to compare devfs and udev again.  With
the exception of this message...

The Problems:
 1) A static /dev is unwieldy and big.  It would be nice to only show
    the /dev entries for the devices we actually have running in the
    system.
 2) We are (well, were) running out of major and minor numbers for
    devices.
 3) Users want a way to name devices in a persistent fashion (i.e. "This
    disk here, must _always_ be called "boot_disk" no matter where in
    the scsi tree I put it", or "This USB camera must always be called
    "camera" no matter if I have other USB scsi devices plugged in or
    not.")
 4) Userspace programs want to know when devices are created or removed,
    and what /dev entry is associated with them.

The constraints:
 1) No policy in the kernel!
 2) Follow standards (like the LSB)
 3) must be small so embedded devices will use it.


So, how does devfs stack up to the above problems and constraints:
  Problems:
    1) devfs only shows the dev entries for the devices in the system.
    2) devfs does not handle the need for dynamic major/minor numbers
    3) devfs does not provide a way to name devices in a persistent
       fashion.
    4) devfs does provide a deamon that userspace programs can hook into
       to listen to see what devices are being created or removed.
  Constraints:
    1) devfs forces the devfs naming policy into the kernel.  If you
       don't like this naming scheme, tough.
    2) devfs does not follow the LSB device naming standard.
    3) devfs is small, and embedded devices use it.  However it is
       implemented in non-pagable memory.

Oh yeah, and there are the insolvable race conditions with the devfs
implementation in the kernel, but I'm not going to talk about them right
now, sorry.  See the linux-kernel archives if you care about them (and
if you use devfs, you should care...)

So devfs is 2 for 7, ignoring the kernel races.

And now for udev:
  Problems:
    1) using udev, the /dev tree only is populated for the devices that
       are currently present in the system.
    2) udev does not care about the major/minor number schemes.  If the
       kernel tomorrow switches to randomly assign major and minor numbers
       to different devices, it would work just fine (this is exactly
       what I am proposing to do in 2.7...)
    3) This is the main reason udev is around.  It provides the ability
       to name devices in a persistent manner.  More on that below.
    4) udev emits D-BUS messages so that any other userspace program
       (like HAL) can listen to see what devices are created or removed.
       It also allows userspace programs to query it's database to see
       what devices are present and what they are currently named as
       (providing a pointer into the sysfs tree for that specific device
       node.)
  Constraints:
    1) udev moves _all_ naming policies out of the kernel and into
       userspace.
    2) udev defaults to using the LSB device naming standard.  If users
       want to deviate away from this standard (for example when naming
       some devices in a persistent manner), it is easily possible to do
       so.
    3) udev is small (49Kb binary) and is entirely in userspace, which
       is swapable, and doesn't have to be running at all times.

Nice, 7 out of 7 for udev.  Makes you think the problems and constraints
were picked by a udev developer, right?  No, the problems and
constraints are ones I've seen over the years and so udev, along with
the kernel driver model and sysfs, were created to solve these real
problems.  I also have had the luxury to see the problems that the
current devfs implementation has, and have taken the time to work out
something that does not have those same problems.

So by just looking at the above descriptions, everyone should instantly
realize that udev is far better than devfs and start helping out udev
development, right?  Oh, you want more info, ok...

Back in May 2003 I released a very tiny version of udev that implemented
everything that devfs currently does, in about 6Kb of userspace code:
	http://marc.theaimsgroup.com/?l=linux-kernel&m=105003185331553

Yes, that's right, 6Kb.  So, you are asking, why are you still working
on udev if it did everything devfs did back in May 2003?  That's because
just managing static device nodes based on what the kernel calls the
devices is _not_ the primary goal of udev.  It's just a tiny side affect
of it's primary goal, the ability to never worry about major/minor
number assignments and provide the ability to achieve persistent device
names if wanted.

All the people wanting to bring up the udev vs. devfs argument go back
and read the previous paragraph.  Yes, all Gentoo users who keep filling
up my inbox with smoking emails, I mean you.

So, how well does udev solve it's goals:
  Prevent users from ever worrying about major/minor numbers
    And here you were, not knowing you ever needed to worry about
    major/minor numbers in the first place, right?  Ah, I see you
    haven't plugged in 2 USB printers and tried to figure out which
    printer was which /dev entry?  Or plugged in 4000 SCSI disks and
    tried to figure out how to access that 3642nd disk and what it was
    called in /dev.  Or plugged in a USB camera and a USB flash drive
    and then tried to download the pictures off of the flash drive by
    accident?

    As the above scenarios show, both desktop users and big iron users
    both need to not worry about which device is assigned to what
    major/minor device.
   
    udev doesn't care what major/minor number is assigned to a device.
    It merely takes the numbers that the kernel says it assigned to the
    device and creates a device node based on it, which the user can
    then use (if you don't understand the whole major/minor to device
    node issue, or even what a device node is, trust me, you don't
    really want to, go install udev and don't worry about it...)  As
    stated above, if the kernel decides to start randomly assigning
    major numbers to all devices, then udev will still work just fine.

  Provide a persistent device naming solution:
    Lots of people want to assign a specific name that they can talk to
    a device to, no matter where it is in the system, or what order they
    plugged the device in.  USB printers, SCSI disks, PCI sound cards,
    Firewire disks, USB mice, and lots of other devices all need to be
    assigned a name in a consistent manner (udev doesn't handle network
    devices, naming them is already a solved solution, using nameif).
    udev allows users to create simple rules to describe what device to
    name.  If users want to call a program running a large database
    half-way around the world, asking it what to name this device, it
    can.  We don't put the naming database into the kernel (like other
    Unix variants have), everything is in userspace, and easily
    accessible.  You can even run a perl script to name your device if
    you are that crazy...

    For more information on how to create udev rules to name devices,
    please see the udev man page, and look at the example udev rules
    that ship with the tarball.
 

So, convinced already why you should use udev instead of devfs?  No.
Ok, fine, I'm not forcing you to abandon your bloated, stifling policy,
nonextensible, end of life feature if you don't want to.  But please
don't bother me about it either, I don't care about devfs, only about
udev.

This is my last posting about this topic, all further emails sent to me
about why devfs is wonderful, and why are you making fun of this
wonderful, stable gift from the gods, will be gleefully ignored and
possibly posted in a public place where others can see.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 158+ messages in thread
end of thread, other threads:[~2004-01-12 20:59 UTC | newest]

Thread overview: 158+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-08 13:05 udev and devfs - The final word "Andrey Borzenkov" 
  -- strict thread matches above, loose matches on Subject: below --
2004-01-08 13:53 "Andrey Borzenkov" 
2004-01-08 15:40 ` Ian Kent
2004-01-08 17:26   ` Diego Calleja
2004-01-08 19:25     ` Andrey Borzenkov
2004-01-08 22:40       ` Alex Goddard
2004-01-09  7:03         ` "Andrey Borzenkov" 
2004-01-08 18:14   ` Alex Goddard
2004-01-08 18:35     ` Alex Goddard
2004-01-08 19:22     ` Andrey Borzenkov
2004-01-09  8:51 ` Helge Hafting
2004-01-06  1:20 Paul Zimmerman
     [not found] <fa.flhsork.uka2hg@ifi.uio.no>
     [not found] ` <fa.hv9hpq7.1l1q9p3@ifi.uio.no>
2004-01-01 19:53   ` walt
2004-01-01 21:53     ` Martin Schlemmer
2004-01-01 16:59 Shaheed
     [not found] <fa.af64864.ugabhg@ifi.uio.no>
     [not found] ` <fa.de7jae9.1jk0pjt@ifi.uio.no>
2003-12-31 22:17   ` walt
2004-01-01  2:03     ` Martin Schlemmer
2004-01-01  2:05       ` Martin Schlemmer
     [not found] <18Cz7-7Ep-7@gated-at.bofh.it>
2003-12-31  3:05 ` Pascal Schmidt
2003-12-31 19:23   ` Greg KH
2003-12-31 20:19     ` Rob Love
2003-12-31 22:01       ` Nathan Conrad
2003-12-31 22:20         ` Rob Love
2003-12-31 21:45           ` Tommi Virtanen
2003-12-31 23:10             ` Rob Love
2003-12-31 21:52               ` Tommi Virtanen
2004-01-02  0:17                 ` Hollis Blanchard
2004-01-02  0:36                   ` viro
2004-01-03  6:04                   ` Greg KH
2003-12-31 22:55           ` viro
2003-12-31 23:05             ` Rob Love
2003-12-31 23:48             ` Andreas Dilger
2004-01-07 10:15             ` Olaf Hering
2004-01-07 11:18               ` viro
2004-01-07 13:00                 ` Olaf Hering
2004-01-07 13:26                   ` viro
2004-01-07 13:27                     ` Olaf Hering
2004-01-01  0:15       ` Andries Brouwer
2004-01-01  0:31         ` Rob Love
2004-01-01 12:34           ` Rob Landley
2004-01-01 15:22             ` Rob Love
2004-01-01 15:48               ` Andries Brouwer
2004-01-01 15:54                 ` Rob Love
2004-01-02 20:42                   ` Linus Torvalds
2004-01-03  3:00                     ` Andries Brouwer
2004-01-03  4:46                       ` Linus Torvalds
2004-01-03 13:10                         ` Andries Brouwer
2004-01-03 22:27                           ` Linus Torvalds
2004-01-03 23:08                             ` Andries Brouwer
2004-01-04  1:16                               ` Mark Mielke
2004-01-04  1:54                                 ` Valdis.Kletnieks
2004-01-04 18:44                                   ` Mark Mielke
2004-01-04  2:09                               ` Linus Torvalds
2004-01-04  2:49                                 ` Andries Brouwer
2004-01-04  3:04                                   ` Linus Torvalds
2004-01-04 13:21                                     ` Andries Brouwer
2004-01-04 21:05                                       ` Linus Torvalds
2004-01-04 22:01                                         ` Andries Brouwer
2004-01-04 22:37                                           ` viro
2004-01-05  1:02                                             ` Mark Mielke
2004-01-05  2:24                                               ` Valdis.Kletnieks
2004-01-05  2:29                                             ` Andries Brouwer
2004-01-05  3:42                                               ` viro
2004-01-04 22:37                                           ` Helge Hafting
2004-01-04 23:35                                           ` Valdis.Kletnieks
2004-01-05  1:43                                             ` Jeremy Maitin-Shepard
2004-01-05  1:58                                               ` viro
2004-01-05  2:12                                                 ` Jeremy Maitin-Shepard
2004-01-05  2:52                                           ` Linus Torvalds
2004-01-05  3:06                                             ` David Lang
2004-01-05  3:48                                               ` Rob Landley
2004-01-05  4:52                                                 ` Trond Myklebust
2004-01-05 15:13                                                 ` Mark Mielke
2004-01-05 16:36                                                   ` Andreas Schwab
2004-01-05 22:18                                                     ` Mark Mielke
2004-01-05  3:07                                             ` Daniel Jacobowitz
2004-01-05  3:33                                               ` Linus Torvalds
2004-01-05  3:50                                                 ` viro
2004-01-05  4:02                                                   ` Linus Torvalds
2004-01-05  4:38                                                     ` viro
2004-01-05  4:52                                                       ` Linus Torvalds
2004-01-05  6:11                                                         ` viro
2004-01-05  7:47                                                         ` Greg KH
2004-01-05 11:15                                                           ` Vojtech Pavlik
2004-01-05 20:11                                                             ` Theodore Ts'o
2004-01-05 21:06                                                               ` Vojtech Pavlik
2004-01-05 22:22                                                                 ` Theodore Ts'o
2004-01-06  0:14                                                                 ` Rob Landley
2004-01-11 22:12                                                         ` Ed L Cashin
2004-01-05  5:26                                                       ` Eric W. Biederman
2004-01-05  7:39                                                       ` Greg KH
2004-01-07  9:57                                                     ` Pavel Machek
2004-01-05 12:27                                                 ` Andries Brouwer
2004-01-05 16:13                                                   ` Linus Torvalds
2004-01-05 17:29                                                     ` Vojtech Pavlik
2004-01-05 17:33                                                       ` Linus Torvalds
2004-01-05 17:52                                                       ` Davide Libenzi
2004-01-05 18:03                                                         ` Linus Torvalds
2004-01-05 18:09                                                         ` Hugo Mills
2004-01-05 19:10                                                         ` Paul Rolland
2004-01-05 19:52                                                     ` Andries Brouwer
2004-01-05 20:38                                                       ` Linus Torvalds
2004-01-05 22:17                                                         ` Shawn
2004-01-05 22:25                                                           ` Mark Mielke
2004-01-05 23:05                                                             ` Shawn
2004-01-05 23:23                                                               ` Shawn
2004-01-06  0:43                                                               ` Greg KH
2004-01-06  0:53                                                                 ` Shawn
2004-01-05 23:13                                                         ` Andries Brouwer
2004-01-05 23:32                                                           ` Linus Torvalds
2004-01-06  0:59                                                             ` viro
2004-01-06  1:17                                                               ` Linus Torvalds
2004-01-06  4:28                                                                 ` viro
2004-01-06  5:07                                                                   ` Linus Torvalds
2004-01-06  1:06                                                             ` Andries Brouwer
2004-01-06 15:00                                                               ` Mark Mielke
2004-01-06  0:00                                                           ` Greg KH
2004-01-06  1:41                                                             ` Andries Brouwer
2004-01-07 17:14                                                               ` Greg KH
2004-01-06  0:31                                                           ` Rob Landley
2004-01-06  7:14                                                       ` Vojtech Pavlik
2004-01-05  7:44                                             ` James H. Cloos Jr.
2004-01-05  7:45                                               ` Nigel Cunningham
2004-01-05 11:01                                                 ` Robin Rosenberg
2004-01-05 12:39                                                   ` Nigel Cunningham
2004-01-07 13:39                                                     ` Robin Rosenberg
2004-01-07 17:16                                                       ` Nigel Cunningham
2004-01-05  9:06                                               ` Valdis.Kletnieks
2004-01-05  4:15                                           ` Peter Chubb
2004-01-05  4:42                                             ` Linus Torvalds
2004-01-01 19:43             ` Kai Henningsen
2004-01-02  7:26               ` Rob Landley
2004-01-04  8:57                 ` Greg KH
2004-01-04  9:43                   ` Rob Landley
2004-01-02  0:17             ` Maciej Zenczykowski
     [not found]               ` <20040102103104.GA28168@mark.mielke.cc>
2004-01-03  6:07                 ` Greg KH
2004-01-03  6:51                   ` Valdis.Kletnieks
2004-01-03 11:57                     ` Ian Kent
2004-01-03 22:08                     ` Greg KH
2004-01-07 10:23             ` Olaf Hering
2004-01-01 23:14           ` Rob
2004-01-02  3:53             ` Tyler Hall
2004-01-01 16:17     ` Pascal Schmidt
2004-01-01 20:03       ` Greg KH
2003-12-31  0:29 Greg KH
2003-12-31  0:53 ` Prakash K. Cheemplavam
2003-12-31 19:17   ` Greg KH
2004-01-02 16:45     ` Shawn
2003-12-31 12:43 ` Paulo Marques
2004-01-01  1:18 ` Helge Hafting
2004-01-03  5:59   ` Greg KH
2004-01-03 15:22     ` Helge Hafting
2004-01-03 21:18       ` viro
2004-01-03 22:11       ` Greg KH
     [not found]     ` <20040103140140.3b848e9f.witukind@nsbm.kicks-ass.org>
2004-01-03 22:16       ` Greg KH
2004-01-03 22:33         ` Christoph Hellwig
2004-01-02 17:54 ` Andreas Jellinghaus
2004-01-02 18:19   ` Shawn

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).