[lkml]   [2003]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] support for sysfs string based properties for SCSI (1/3)
    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

    > 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:35    [W:0.020 / U:2.332 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site