From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: viro@parcelfarce.linux.theplanet.co.uk, "Perez-Gonzalez,
Inaky" <inaky.perez-gonzalez@intel.com>,
"'Kevin P. Fleming'" <kpfleming@cox.net>,
"'Patrick Mochel'" <mochel@osdl.org>,
"'Russell King'" <rmk@arm.linux.org.uk>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: Flaw in the driver-model implementation of attributes
Date: Wed, 18 Jun 2003 10:15:27 -0700 [thread overview]
Message-ID: <20030618171527.GA1415@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0306181018540.741-100000@ida.rowland.org>
On Wed, Jun 18, 2003 at 10:32:22AM -0400, Alan Stern wrote:
> On Wed, 18 Jun 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> > BS. There is nothing to stop you from having a block device that talks
> > to userland process instead of any form of hardware. As the matter of
> > fact, we already have such a beast - nbd. There is also RAID - where
> > there fsck is 1:1 here? There's also such thing as RAID5 over partitions
> > that sit on several disks - where do you see 1:1 or 1:n or n:1?
> > There is such thing as e.g. encrypted loop over NFS. There are all
> > sorts of interesting things, with all sorts of interesting relationship
> > to some pieces of hardware.
>
> This is the sort of thing that bothers me. Block devices deserve their
> own "view", so we have /sys/block/ -- perhaps to be renamed
> /sys/class/block/. Fine.
>
> But what other sorts of things deserve their own "view" as well? Some
> are already established, maybe others aren't. How's a developer supposed
> to know whether the driver he's working on deserves its own entry in
> /sys/class/ or not? How's a user supposed to know where in the hierarchy
> to look for a particular device?
Ok, have you _read_ the documentation on the driver model? In it,
classes and devices are clearly spelled out as to what the differences
are, and what shows up where.
See Pat's linux.conf.au 2003 paper for much more detail.
And yes, I need to fix up the Documentation/driver_model/class.txt with
the most recent info...
In short, devices describe physical things that are present in the
computer system. Classes describe a type of device, be it virtual or
physical. Almost always, classes refer to something a user uses through
the /dev filesystem (like mice, tty, block, audio, etc.)
So no, there is not always a 1:1 mapping from classes to devices, that
is why the driver model does not enforce such a mapping at all. You can
have multiple "struct class_device" structures that point to the same
"struct device" or no "struct device" at all.
Hope this helps to clear up the confusion that seems to be happening.
thanks,
greg k-h
next prev parent reply other threads:[~2003-06-18 17:02 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-18 7:48 Flaw in the driver-model implementation of attributes Perez-Gonzalez, Inaky
2003-06-18 8:12 ` viro
2003-06-18 14:32 ` Alan Stern
2003-06-18 17:15 ` Greg KH [this message]
2003-06-18 19:50 ` Alan Stern
2003-06-19 16:42 ` Patrick Mochel
2003-06-19 21:18 ` Alan Stern
2003-06-19 14:13 ` Alan Stern
2003-06-19 17:07 ` Patrick Mochel
2003-06-19 21:14 ` Alan Stern
2003-06-19 21:31 ` Greg KH
2003-06-20 14:22 ` Alan Stern
2003-06-20 18:32 ` Greg KH
2003-07-02 22:12 ` Greg KH
2003-07-03 14:51 ` Alan Stern
2003-06-20 20:05 ` Host drivers and conversion of SCSI to the driver model Alan Stern
2003-06-20 21:07 ` Mike Anderson
2003-06-23 14:57 ` Alan Stern
2003-06-27 10:03 ` Christoph Hellwig
2003-06-27 17:56 ` Alan Stern
2003-06-27 18:04 ` Christoph Hellwig
2003-06-27 19:23 ` Mike Anderson
2003-06-28 8:34 ` Christoph Hellwig
2003-06-28 15:08 ` Jeff Garzik
2003-06-28 15:12 ` Christoph Hellwig
2003-07-03 15:15 ` Alan Stern
2003-07-06 16:04 ` Christoph Hellwig
2003-07-03 21:02 ` scsi_forget_host() and scsi_remove_device() Alan Stern
2003-07-03 22:19 ` Mike Anderson
2003-07-04 14:16 ` Alan Stern
2003-07-04 19:36 ` Alan Stern
2003-07-04 19:54 ` Matthew Dharm
2003-07-05 14:11 ` Alan Stern
2003-07-05 16:25 ` Matthew Dharm
2003-07-06 16:13 ` Christoph Hellwig
2003-07-07 15:19 ` PATCH: (as54) Fix hot-unplugging for sr.c Alan Stern
2003-07-08 22:29 ` Mike Anderson
2003-07-09 14:04 ` Alan Stern
2003-07-09 14:44 ` Mike Anderson
2003-07-09 16:02 ` Alan Stern
2003-07-31 19:38 ` PATCH: (as33e) Fix removal of /proc/scsi/hostdir on hot-unplug Alan Stern
2003-08-01 20:03 ` Mike Anderson
2003-08-15 20:05 ` PATCH: (as84) Fix my earlier scsi procdir patch Alan Stern
2003-09-16 14:50 ` PATCH: (as84) Small fixup for SCSI proc code Alan Stern
2003-10-16 21:09 ` Race in removal of host class device attribute file Alan Stern
2003-10-16 22:47 ` Mike Anderson
2003-10-17 12:18 ` Alan Stern
2003-10-17 12:30 ` Christoph Hellwig
2003-12-10 15:02 ` Suggestion for aiding debugging of host removal Alan Stern
2003-12-10 15:14 ` Christoph Hellwig
2003-12-11 4:16 ` DMA Timeout with Promise S150TX4 and 2.6.0-test11-bk8 Paul
2003-12-11 7:48 ` Suggestion for aiding debugging of host removal Mike Anderson
2003-12-11 11:39 ` Christoph Hellwig
2003-12-11 15:14 ` Alan Stern
2003-07-06 16:11 ` scsi_forget_host() and scsi_remove_device() Christoph Hellwig
2003-07-07 16:06 ` Alan Stern
2003-07-03 20:20 ` SCSI documentation in scsi_mid_low_api.txt Alan Stern
2003-07-03 20:42 ` aic7xxx driver schedules() while holding spinlock Tony Battersby
2003-06-19 17:26 ` Flaw in the driver-model implementation of attributes Mike Anderson
-- strict thread matches above, loose matches on Subject: below --
2003-06-19 21:18 Perez-Gonzalez, Inaky
2003-06-19 0:06 Clayton Weaver
2003-06-19 0:20 ` Kevin P. Fleming
2003-06-19 16:46 ` Patrick Mochel
2003-06-18 19:52 Perez-Gonzalez, Inaky
2003-06-18 3:44 Perez-Gonzalez, Inaky
2003-06-18 4:18 ` viro
[not found] <20030616194446.H13312@flint.arm.linux.org.uk>
2003-06-16 19:36 ` Alan Stern
2003-06-16 20:49 ` Patrick Mochel
2003-06-16 21:29 ` Alan Stern
2003-06-16 22:43 ` Patrick Mochel
2003-06-17 19:49 ` Alan Stern
2003-06-18 1:38 ` Kevin P. Fleming
2003-06-16 23:36 ` Greg KH
2003-06-17 17:29 ` Alan Stern
2003-06-17 17:33 ` Greg KH
2003-06-17 20:20 ` Alan Stern
2003-06-15 16:42 Alan Stern
2003-06-15 17:40 ` Jeremy Fitzhardinge
2003-06-16 14:05 ` Alan Stern
2003-06-16 17:08 ` Greg KH
2003-06-16 17:20 ` Russell King
2003-06-16 17:54 ` Alan Stern
2003-06-16 18:00 ` Patrick Mochel
2003-06-16 18:03 ` viro
2003-06-16 18:23 ` Alan Stern
2003-06-16 18:38 ` Patrick Mochel
2003-06-16 19:06 ` Alan Stern
2003-06-16 18:00 ` Martin Diehl
2003-06-16 18:15 ` viro
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=20030618171527.GA1415@kroah.com \
--to=greg@kroah.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=kpfleming@cox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=rmk@arm.linux.org.uk \
--cc=stern@rowland.harvard.edu \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.