All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.