public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Bell <kernel@mikebell.org>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: [ANNOUNCE] ndevfs - a "nano" devfs
Date: Mon, 27 Jun 2005 16:26:00 -0700	[thread overview]
Message-ID: <20050627232559.GA7690@mikebell.org> (raw)
In-Reply-To: <200506271735.50565.dtor_core@ameritech.net>

On Mon, Jun 27, 2005 at 05:35:50PM -0500, Dmitry Torokhov wrote:
> AFAIK there is no requirement in input subsystem that devices should be
> created under /dev/input. When devfs is activated they are created there
> by default, but that's it.

Things which accept a path to an event file as an argument will work
just fine. But anything which tries autodiscovery HAS to be able to find
the device nodes. Think directfb, most (but not all) of the X patches,
any user-space driver that wants to find the hardware it owns, etc.

This illustrates nicely my reasons for preferring devfs.

1) Predictable, canonical device names are a Good Thing.

2) If you accept that, exporting the device names from the kernel is the
most sensible way to do it.

For point one, how do you do autodiscovery otherwise? You can look at
sysfs or /proc/bus/input/devices to find out what input devices are on
the system, but if the device nodes can be named anything then how do
you find them? Grep over all of /dev and find the guy with the right
major/minor? Or create your own private device node using the dev sysfs
parameter? Or use some crazy interface to udev's configuration files to
find out what the hell it decided to name the node?

For point two, without doubting the need for a userspace utility to do
chown and symlinks to meaningful names, I cannot conceive of how anyone
could say "I need a device node named /dev/input/event0 with this
major/minor created and deleted according to in-kernel events. The best
way to do this is to export an empty ram-backed filesystem and mount it
on /dev from userspace, use a second kernel-generated filesystem to
export a file called /sys/class/input/event0/dev with the major and
minor in it, use a second kernel->userspace interface to send an event
to a userspace helper which will read that value, look up that it's
supposed to be named /dev/input/event0, and mknod the corresponding
device file". Not if the node is always going to be named
/dev/input/event0.

udev can do lots of amazing things, but ONE of the things it does,
creating device nodes, could be done much better in the kernel IMHO. The
only thing udev offers over a devfs-like solution in this regard is the
ability to have those device nodes use all sorts of wacky, random names.
And that's not a feature in my book, it's a colossal bug. If you want
wacky, random names, make them symlinks. And please don't confuse hatred
for ide/host0/bus0/target0/lun0/part1 versus hda1 with hatred of
standardized names. Picking a dumb standard one time doesn't mean
standards are dumb.


  reply	other threads:[~2005-06-27 23:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-24  8:18 [ANNOUNCE] ndevfs - a "nano" devfs Greg KH
2005-06-24 12:23 ` Michael Tokarev
2005-06-24 15:16   ` Greg KH
2005-06-24 15:40     ` Michael Tokarev
2005-06-24 16:26       ` Greg KH
2005-06-24 14:32 ` Bill Gatliff
2005-06-24 15:17 ` Steven Rostedt
2005-06-24 15:20   ` Greg KH
2005-06-24 17:10 ` Michael Tokarev
2005-06-24 17:10 ` Bill Gatliff
2005-06-28  7:40   ` Greg KH
2005-06-24 19:05 ` Mike Bell
2005-06-24 21:55   ` J.A. Magallon
2005-06-24 19:22 ` Alexey Dobriyan
2005-06-25  0:57 ` Kyle Moffett
2005-06-25  7:37   ` Denis Vlasenko
2005-06-28  7:41   ` Greg KH
2005-06-28 19:56     ` Tom Rini
2005-06-28 21:08       ` Olaf Hering
2005-06-28 21:25         ` Tom Rini
2005-06-28 22:08           ` Michael Tokarev
2005-06-28 22:23             ` Tom Rini
2005-06-25 22:15 ` Matt Mackall
2005-06-25 23:43   ` Greg KH
2005-06-26  8:23     ` Russell King
2005-06-28  3:36       ` Greg KH
2005-06-27  7:19     ` Mike Bell
2005-06-27 22:35       ` Dmitry Torokhov
2005-06-27 23:26         ` Mike Bell [this message]
2005-06-28  7:40           ` Greg KH
2005-06-28  9:08             ` Mike Bell
2005-06-28  9:21               ` Arjan van de Ven
2005-06-28  9:40                 ` Mike Bell
2005-06-28 21:49                 ` Jim Crilly
2005-06-28 22:23                   ` Mike Bell
2005-06-28 23:43                     ` Jim Crilly
2005-06-29  0:12                       ` Mike Bell
2005-06-29  0:39                         ` David Lang
2005-06-29  0:53                           ` Mike Bell
2005-06-28 12:00             ` Oliver Neukum
2005-06-28 20:08               ` Greg KH
2005-06-29  6:41                 ` Oliver Neukum
2005-06-29 16:06                   ` Greg KH
2005-06-29 16:22                     ` Oliver Neukum
     [not found] ` <200506270819.20108.arnd@arndb.de>
2005-06-28  3:46   ` Greg KH
     [not found] <OF831AC472.851744FE-ON8025702A.004A57EC-8025702A.004B5AE9@sophos.com>
2005-06-24 15:23 ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-06-24 15:32 tvrtko.ursulin
2005-06-24 16:27 ` Greg KH
2005-06-27 15:21 Adam J. Richter
2005-06-27 23:27 ` J.A. Magallon

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=20050627232559.GA7690@mikebell.org \
    --to=kernel@mikebell.org \
    --cc=dtor_core@ameritech.net \
    --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