From: James Bottomley <James.Bottomley@steeleye.com>
To: Greg KH <greg@kroah.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
Patrick Mochel <mochel@osdl.org>,
Mike Anderson <andmike@us.ibm.com>
Subject: Re: [RFC] support for sysfs string based properties for SCSI (1/3)
Date: 05 May 2003 19:05:52 -0500 [thread overview]
Message-ID: <1052179553.1888.461.camel@mulgrave> (raw)
In-Reply-To: <20030505171745.GA1477@kroah.com>
On Mon, 2003-05-05 at 12:17, Greg KH wrote:
> On Mon, May 05, 2003 at 12:08:35PM -0500, James Bottomley wrote:
> > Nothing prevents users from doing it the callback way. However,
> > callbacks aren't a scaleable interface for properties that have to be
> > shared and overridden.
>
> I don't understand the "shared and overridden" aspect. Do you mean a
> default attribute for all types of SCSI devices, with the ability for an
> individual device to override the attribute with it's own values if it
> wants to? That still seems doable within the driver model today,
> without having to rely on bus specific functions.
Yes, but the problem is how to communicate the override between the HBA
driver and SCSI. The override is required because changing some
properties may require changes at many levels. The queue_depth in the
example I gave is the obvious one:
- the device needs to make sure it has internal resources for the
revised queue depth. It also has to implement the change.
- the mid-layer needs to do the adjustment
- As does the block layer (I didn't implement this one in my patch).
The interface obviously belongs in the SCSI API, but one API entry per
property causes the interface to explode and also makes it quite
difficult to add new ones, so we need a generic get/set property
interface; however, then we need to know what property, hence the
strings.
> Hm, this is _really_ calling for what Pat calls "attributes". Take a
> look at the ones in the class model, and let me know if those would work
> for you for devices. If so, I'll be glad to add them, which should help
> you out here.
Well, I analysed the class interface. It currently won't do what we
need, but it might be able to if it supported an inheritance, so there
would be a device class which could then be extended by the drivers to
override the properties they need. However, isn't this type of
inheritance going to be a real pain using function pointers, and if we
only support overrides of show/store, it's probably simpler just to
support the strings based interface.
James
next prev parent reply other threads:[~2003-05-06 0:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-03 19:11 [RFC] support for sysfs string based properties for SCSI (1/3) James Bottomley
2003-05-03 19:19 ` James Bottomley
2003-05-03 19:25 ` [RFC] support for sysfs string based properties for SCSI (2/3) James Bottomley
2003-05-03 19:30 ` [RFC] support for sysfs string based properties for SCSI (3/3) James Bottomley
2003-05-05 17:02 ` [RFC] support for sysfs string based properties for SCSI (1/3) Greg KH
2003-05-05 17:08 ` James Bottomley
2003-05-05 17:17 ` Greg KH
2003-05-05 20:08 ` Mike Anderson
2003-05-06 0:05 ` James Bottomley [this message]
2003-05-13 21:02 ` Patrick Mochel
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=1052179553.1888.461.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=andmike@us.ibm.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mochel@osdl.org \
/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