public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: dtor_core@ameritech.net, Greg KH <gregkh@suse.de>,
	Vojtech Pavlik <vojtech@suse.cz>, Hannes Reinecke <hare@suse.de>,
	Patrick Mochel <mochel@digitalimplant.org>,
	airlied@linux.ie, linux-kernel@vger.kernel.org,
	Adam Belay <ambx1@neo.rr.com>
Subject: Re: [patch 0/8] Nesting class_device patches that actually work
Date: Fri, 14 Oct 2005 15:49:23 +0200	[thread overview]
Message-ID: <20051014134923.GA22373@vrfy.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0510140839290.16066@chaos.analogic.com>

On Fri, Oct 14, 2005 at 08:49:52AM -0400, linux-os (Dick Johnson) wrote:
> 
> On Fri, 14 Oct 2005, Kay Sievers wrote:
> 
> > On Fri, Oct 14, 2005 at 10:45:54AM +0200, Kay Sievers wrote:
> >> On Thu, Oct 13, 2005 at 04:35:25PM -0500, Dmitry Torokhov wrote:
> >>> On 10/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >>>>
> >>>> The nesting classes implement a fraction of a device hierarchy in
> >>>> /sys/class. It moves arbitrary relation information into the class
> >>>> directory, where nothing else than device classification belongs.
> >>>> What is the rationale behind sticking device trees into class?
> >>>>
> >>>> Instead of that, I propose a unification of "/sys/devices-devices"
> >>>> and "class-devices". The differentiation of both does not make sense
> >>>> in a wold where we can't really tell if a device is hardware or virtual.
> >>>>
> >>>> We should model _all_ devices with its actual realationship in
> >>>> /sys/devices and /sys/class should only be a pinter to the actual
> >>>> devices in that place. Device like "mice", which have no parent, would
> >>>> sit at the top level of /sys/devices. All devices in /sys/class are
> >>>> only symlinks and never devices by itself.
> >>>> That way userspace can read all device relation at _one_ place in a sane
> >>>> way, and we keep the clean class interface to have easy access to all
> >>>> devices of a specific group.
> >>>> It gives us the right abstraction and is future proof, cause
> >>>> the class interface will not change when the relation between devices
> >>>> changes. The destinction between classes and buses would no longer be
> >>>> needed, and as we see in the "input" case never made sense anyway.
> >>>>
> >>>> /sys/class/block would look exactly like /sys/block today. The only
> >>>> difference is that there are symlinks to follow instead of class devices
> >>>> on its own. With every device creation we will get the whole dependency
> >>>> path of the device in the DEVPATH and a "classsification symlink" in
> >>>> /sys/class. The input devices are all clearly modeled in its hierarchy,
> >>>> in /sys/devices but we also get clean class interfaces:
> >>>>
> >>>
> >>> Kay eased my task by enumerating all issues I have with Greg's
> >>> approach. Not all the world is udev and not all class devices have
> >>> "/dev" represetation so haveing one program being able to understand
> >>> new sysfs hierarchy is not enough IHMO.
> >>>
> >>> However I do not think that "moving" class devices into /sys/devices
> >>> hierarchy is the right solution either because one physical device
> >>> could easily end up belonging to several classes.
> >>
> >> Sure, than that physical (while that distinction is silly by itself)
> >> will just have several child devices. Look at the mouse0 and event0 in
> >> the ascii drawing.
> >>
> >>> I recenty got an
> >>> e-mail from Adam Belay (whom I am pulling into the discussion)
> >>> regarding his desire to rearrange net/wireless representation. I think
> >>> it would be quite natural to have /sys/class/net/interfaces and
> >>> /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired
> >>> subclasses where "interfaces" would enumerate _all_ network interfaces
> >>> in the system, and the rest would show only devices of their class.
> >>
> >> That solution would keep a better device separation, sure. But it
> >> is completely incompatible with everything we ever had in sysfs and
> >> nobody wants to rewrite _all_ userspace programs.
> >>
> >> It invents artificial subclass names below a "master" class, which
> >> is absolutely not needed.
> >>
> >> It creates the magic "interfaces" directory, which is confusing, cause
> >> it classifies devices by itself.
> >>
> >> It doesn't represent any relationship and hierarchy of devices and
> >> adding a forest of magic symlinks and "device" pointers is a very
> >> bad design. The proposed "inter-class" symlinks make it even harder
> >> to understand sysfs as it already is.
> >>
> >> The biggest problem with current sysfs is that the driver hacker has to
> >> decide if the device is "hardware" or "virtual" which in a lot of
> >> cases just can't tell and this distiction doesn't make any sense today.
> >>
> >> All the more complex subsystems use "virtual buses" and an unconnected
> >> bunch of class-devices to model its sysfs represention, which is just
> >> to work around a major design flaw in sysfs!
> >> We really should get _one_ device tree with its natural hierarchy, get
> >> rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected
> >> class devices. Every device should just carry its dependency tree in
> >> it _own_ devpath!
> >>
> >> I'm very sure, we want a unified tree in /sys/devices, regardless of the type
> >> of device, to represent the global hierarchy wich is exactly what you want to
> >> know from a device tree!
> >> That way we stack "virtual" _and_ "physical" in a sane manner and at the same
> >> time get very clean class interfaces. We would stop to mix up "hierarchy" and
> >> "classes" all over the tree.
> >
> > Sorry, my previous drawing wasn't correct for the input devices.
> >
> > Here is a new picture of the:
> >  - all classes are unique and flat and will stay the same,
> >    even when the hierarchy of the devices changes
> >  - all hierarchy is _only_ in /sys/devices
> >  - virtual and physical devices are both in /sys/devices
> > proposal.
> >
> > /sys
> > |-- class
> > |   |-- block
> > |   |   `-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda
> > |   |-- block_partition
> > |   |   |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda1
> > |   |   `-- sda2 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda2
> > |   |-- pci
> > |   |   `-- 0000:00:1f.2 -> ../../devices/pci0000:00/0000:00:1f.2
> > |   |-- input
> > |   |   |-- mice -> ../../devices/mice
> > |   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
> > |   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
> > |   |-- input_device
> > |   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
> > |   `-- tty
> > |       `-- console -> ../../devices/console
> > |
> > |
> > |-- devices
> > |   |-- pci0000:00
> > |   |   `-- 0000:00:1f.2
> > |   |       |-- class -> ../../../class/pci
> > |   |       |-- config
> > |   |       |-- device
> > |   |       |-- host0
> > |   |       |   `-- target0:0:0
> > |   |       |       |-- 0:0:0:0
> > |   |       |       |   |-- sda
> > |   |       |       |   |   |-- dev
> > |   |       |       |   |   |-- range
> > |   |       |       |   |   |-- removable
> > |   |       |       |   |   |-- sda1
> > |   |       |       |   |   |   |-- dev
> > |   |       |       |   |   |   |-- size
> > |   |       |       |   |   |   |-- start
> > |   |       |       |   |   |   `-- stat
> > |   |       |       |   |   |-- sda2
> > |   |       |       |   |   |   |-- dev
> > |   |       |       |   |   |   |-- size
> > |   |       |       |   |   |   |-- start
> > |   |       |       |   |   |   `-- stat
> > |   |       |       |   |   |-- size
> > |   |       |       |   |    `-- stat
> > |   |       |       |   |-- model
> > |   |       |       |   |-- type
> > |   |       |       |   `-- vendor
> > |   |       |       `-- power
> > |   |       |           `-- state
> > |   |       |-- modalias
> > |   |       |-- resource
> > |   |       |-- subsystem_device
> > |   |       |-- subsystem_vendor
> > |   |       `-- vendor
> > |   |-- platform
> > |   |   `-- i8042
> > |   |       `-- serio0
> > |   |            `-- input0
> > |   |                 |-- event0
> > |   |                 |   `-- dev
> > |   |                 |-- mouse0
> > |   |                 |   `-- dev
> > |   |                 |-- bind_mode
> > |   |                 |-- description
> > |   |                 |-- id
> > |   |                 |   |-- extra
> > |   |                 |   |-- id
> > |   |                 |   |-- proto
> > |   |                 |   `-- type
> > |   |                 |-- modalias
> > |   |                 |-- protocol
> > |   |                 |-- rate
> > |   |                 |-- resetafter
> > |   |                 `-- resolution
> > |   |-- mice
> > |   |   `-- dev
> > ...
> >
> > Thanks,
> > Kay
> 
> I have a great deal of bad experience attempting to perform
> emergency mounts on Sun Workstations that have this same
> general scheme of un-typable:
> 
> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda1
> 
> People need to enter this stuff without the help of cut-and-pase or
> even a back-space that works. Are you trying to replace "/dev/sda1"
> with the monster above? If so, you have way too much time on your
> hands.

Welcome to Linux!
Sysfs was never and will not be involved with mounting or device nodes!

Kay

  reply	other threads:[~2005-10-14 13:49 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051013014147.235668000@echidna.kroah.org>
2005-10-13  2:08 ` [patch 0/8] Nesting class_device patches that actually work Greg KH
2005-10-13  2:10   ` Greg KH
2005-10-13 23:38     ` Kay Sievers
2005-10-13  2:10   ` [patch 1/8] Driver Core: add the ability for class_device structures to be nested Greg KH
2005-10-13  2:10   ` [patch 2/8] Driver Core: fix up all callers of class_device_create() Greg KH
2005-10-13  2:10   ` [patch 3/8] Driver Core: document struct class_device properly Greg KH
2005-10-13  2:10   ` [patch 4/8] input: register the input class device sooner Greg KH
2005-10-13  2:10   ` [patch 5/8] input: export input_dev_class so that input drivers can use it Greg KH
2005-10-13  2:10   ` [patch 6/8] input: move the input class devices under their new input_dev devices Greg KH
2005-10-13  2:11   ` [patch 7/8] input: remove the input_class structure, as it is unused Greg KH
2005-10-13  2:11   ` [patch 8/8] input: rename input_dev_class to input_class to be correct Greg KH
2005-10-13  6:38   ` [patch 0/8] Nesting class_device patches that actually work Vojtech Pavlik
2005-10-13 21:21     ` Dmitry Torokhov
2005-10-13 10:58   ` Kay Sievers
2005-10-13 21:35     ` Dmitry Torokhov
2005-10-13 23:37       ` Hannes Reinecke
2005-10-14  8:45       ` Kay Sievers
2005-10-14 12:14         ` Kay Sievers
2005-10-14 12:49           ` linux-os (Dick Johnson)
2005-10-14 13:49             ` Kay Sievers [this message]
2005-10-17 10:02           ` Vojtech Pavlik
2005-10-18  5:13             ` Dmitry Torokhov
2005-10-14 17:02         ` Dmitry Torokhov
2005-10-15 15:08           ` Kay Sievers
2005-10-17  5:41             ` Dmitry Torokhov
2005-10-17 21:44             ` Greg KH
2005-10-17 21:54               ` Dmitry Torokhov
2005-10-17 23:26                 ` Adam Belay
2005-10-18  0:03                   ` Kay Sievers
2005-10-17 23:24               ` Adam Belay
2005-10-17 23:44                 ` Kay Sievers
2005-10-18  5:26                 ` Greg KH
2005-10-18  7:18                   ` Adam Belay
2005-10-18  7:54                     ` Greg KH
2005-10-18  8:34                     ` Vojtech Pavlik
2005-10-18 15:08                     ` Kay Sievers
2005-10-18 15:41                       ` Dmitry Torokhov
2005-10-18  6:04               ` Greg KH
2005-10-18  7:05                 ` Greg KH
2005-10-18  7:35                   ` Greg KH
2005-10-17  9:26         ` Vojtech Pavlik
2005-12-01 18:59         ` Patrick Mochel
2005-10-14  9:52   ` Christoph Hellwig
2005-10-14 16:36     ` Dmitry Torokhov

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=20051014134923.GA22373@vrfy.org \
    --to=kay.sievers@vrfy.org \
    --cc=airlied@linux.ie \
    --cc=ambx1@neo.rr.com \
    --cc=dtor_core@ameritech.net \
    --cc=gregkh@suse.de \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=mochel@digitalimplant.org \
    --cc=vojtech@suse.cz \
    /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