mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniele Orlandi <daniele@orlandi.com>
To: linux-kernel@vger.kernel.org
Subject: An idea on devfs vs. udev
Date: Sun, 30 Oct 2005 20:07:11 +0200	[thread overview]
Message-ID: <200510301907.11860.daniele@orlandi.com> (raw)


Disclaimer: My knowledge about devfs/udev/sysfs is superficial, all the 
following text maybe nonsense. In case, please ignore it, complain, insult 
me, whatever you prefer, I'm not going to be offended :)


I see /dev as an abstraction layer above /sys, where udev implements the 
abstraction. udev takes information from /sys and "translates" it to device 
files organized in a nice way, following several policies configured on the 
system.

Embedded people say "We don't need that kind of abstraction, we are ok with 
working at the lower level".

So, why cannot we substitute the "dev" file within /sys with the actual device 
file?

udev could continue to work in the same fashion, just stat(2)ing the file, 
instead of parsing its contents.

embedded software could directly access the device file in /sys following a 
path that is often meaningful and persistant between reboots.

This is *not* meant to be alternative to udev, just a possibility for people 
who cannot run hotplug/udev and still want to access dynamic devices and are 
prepared to adapt their software and libraries to another scheme.

Bye,

-- 
  Daniele Orlandi

             reply	other threads:[~2005-10-30 18:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-30 18:07 Daniele Orlandi [this message]
2005-10-30 21:18 ` Neil Brown
2005-10-30 22:23   ` Greg KH
2005-10-30 21:32     ` Neil Brown
2005-11-08 18:41     ` Matt Mackall
2005-11-08 18:51       ` Greg KH
2005-11-08 19:17         ` Matt Mackall
2005-11-08 22:13           ` Bill Davidsen
2005-10-30 21:57 ` Rob Landley
2005-10-31  9:21   ` Frank Sorenson
2005-10-30 22:18 ` Greg KH
2005-10-30 21:35   ` Neil Brown
2005-10-30 21:48     ` Daniele Orlandi

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=200510301907.11860.daniele@orlandi.com \
    --to=daniele@orlandi.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

Powered by JetHome