mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: dtor_core@ameritech.net
Cc: Kay Sievers <kay.sievers@vrfy.org>, Greg KH <gregkh@suse.de>,
	Vojtech Pavlik <vojtech@suse.cz>,
	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 01:37:31 +0200 (CEST)	[thread overview]
Message-ID: <2553895.1129246651478.SLOX.WebMail.wwwrun@imap-dhs.suse.de> (raw)
In-Reply-To: <d120d5000510131435m7b27fe59l917ac3e11b2458c8@mail.gmail.com>

Am Do 13.10.2005 23:35 schrieb Dmitry Torokhov
<dmitry.torokhov@gmail.com>:

> On 10/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
[ ... ]
> >
> > 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.
> >
[ ... ]
> >
>
> Hi,
>
> 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.
>
Do not forget another side effect: we only have 'devices' within a tree
under /sys/devices.
/sys/class is just a mapping with no real devices in them, only
 symlinks.
So _everything_ can be found under /sys/devices, and you don't have to
figure out whether this device your looking for is a class device or a
proper device or whatever.

So we really have unified view for all devices, may they be physical or
logical devices.

> 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. 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.
>
But you can! That was the whole idea behind it.
Every device ends up in /sys/devices, and the class is just a 'view' on
those devices.
(You might even call it API if you feel so inclined).
/sys/class/net/interfaces would be implemented just as a collection of
symlinks onto the proper devices in /sys/devices.

Overall this approach would make so many tasks so much simpler.
We could figure out the dependencies on a given device by just following
up the path; no need for the 'PHYSDEVPATH' stuff we have now for the
events. Plus we could model weird things like the SCSI subsystem onto
sysfs without having to resort to dirty tricks like we do now. Hell, we
maybe can even map the OpenPROM device tree onto sysfs for all I know.

So it definitely looks far superior to what we have now.

Cheers,

Hannes


  reply	other threads:[~2005-10-13 23:37 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 ` 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 [this message]
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
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=2553895.1129246651478.SLOX.WebMail.wwwrun@imap-dhs.suse.de \
    --to=hare@suse.de \
    --cc=airlied@linux.ie \
    --cc=ambx1@neo.rr.com \
    --cc=dtor_core@ameritech.net \
    --cc=gregkh@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®