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: 46+ 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-19 17:26 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox