From: James Bottomley <James.Bottomley@steeleye.com>
To: Greg KH <greg@kroah.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: BUG(?): class_device_driver_link()
Date: 18 Jun 2004 22:28:39 -0500 [thread overview]
Message-ID: <1087615720.2134.233.camel@mulgrave> (raw)
In-Reply-To: <20040619000356.GC24902@kroah.com>
On Fri, 2004-06-18 at 19:03, Greg KH wrote:
> Again, the driver owns the class device. scsi has something wrong
> again. Time to stop avoiding everyone at work...
Well, the SCSI model for using these things isn't exactly the same as a
more standard entity like a PCI device.
For every SCSI device the mid-layer scans, we allocate a generic device.
We have various drivers in the driver model corresponding to our Upper
Layer Drivers (disc[sd] tape[st] etc), although there are SCSI devices
(like processors) that will get no driver at all bound.
We then use classes to export *device* interfaces, like one class of all
devices, another for Parallel interface devices, another for Fibre
Channel devices and so on.
We expect the class interface to work whether or not a driver is
present, because the class as we've implemented it is an interface to a
device property, not a driver property (and we also expect the class
interface to span multiple drivers...tapes and discs may all be attached
to a parallel bus, etc).
It sounds like the mismatch is interface on device rather than interface
on driver, but I don't see a way we could make the interface on driver
work for us because we need the interface even if a driver isn't bound.
James
next prev parent reply other threads:[~2004-06-19 3:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-18 20:12 BUG(?): class_device_driver_link() Alan Stern
2004-06-18 20:23 ` Greg KH
2004-06-18 21:36 ` Alan Stern
2004-06-19 0:03 ` Greg KH
2004-06-19 3:28 ` James Bottomley [this message]
2004-06-20 22:23 ` Alan Stern
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=1087615720.2134.233.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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.