RE: 2.6: how do I this in sysfs?

RE: 2.6: how do I this in sysfs?

[Miller, Mike (OS Dev)]

> This is after my minimal sas transport class, please also 
> read the thread about it on linux-scsi
> 
In the referenced code for using sysfs, there only appear to be methods
for reading attributes.  How about if we want to cause a command to
get written out to the hardware?   Do we do something like this?

        /* get a semaphore keep everyone else out while we're working,
           and hope like hell that all the other processes are playing
           nice and using the semaphore too, or else we're hosed. */

        get_some_kind_of_semaphore();

        fd = open("/sys/blah/blah/attribute1", O_RDWR);
        write(fd, SOME_JUNK1, sizeof(SOME_JUNK1));
        close(fd);
        fd = open("/sys/blah/blah/attribute2", O_RDWR);
        write(fd, SOME_JUNK2, sizeof(SOME_JUNK2));
        close(fd);
        fd = open("/sys/blah/blah/attribute3", O_RDWR);
        write(fd, SOME_JUNK3, sizeof(SOME_JUNK3));
        close(fd);
        fd = open("/sys/blah/blah/attribute4", O_RDWR);
        write(fd, SOME_JUNK4, sizeof(SOME_JUNK4));
        close(fd);
        fd = open("/sys/blah/blah/attribute5", O_RDWR);
        write(fd, SOME_JUNK5, sizeof(SOME_JUNK5));
        close(fd);
        fd = open("/sys/blah/blah/attribute6", O_RDWR);
        write(fd, SOME_JUNK6, sizeof(SOME_JUNK6));
        close(fd);
        fd = open("/sys/blah/blah/attribute7", O_RDWR);
        write(fd, SOME_JUNK7, sizeof(SOME_JUNK7));
        close(fd);

        /* When the attribute write_doorbell is written to, by
convention
           of this particular device "/sys/blah/blah",  it acts as a
           doorbell which causes all the values which were "latched" by
           the above writes to be consolidated into one command and
           written to the hardware.  */

        fd = open("/sys/blah/blah/write_doorbell", O_RDWR);
        write(fd, "ding dong", 9);
        close(fd);

        release_some_kind_of_semaphore();

I'm not suggesting that the above is a good idea.  I don't have a good
idea about how to do this.

Re: 2.6: how do I this in sysfs?

[Greg KH]

On Mon, Aug 29, 2005 at 12:24:18PM -0500, Miller, Mike (OS Dev) wrote:
> 
> > This is after my minimal sas transport class, please also 
> > read the thread about it on linux-scsi
> > 
> In the referenced code for using sysfs, there only appear to be methods
> for reading attributes.  How about if we want to cause a command to
> get written out to the hardware?   Do we do something like this?
> 
>         /* get a semaphore keep everyone else out while we're working,
>            and hope like hell that all the other processes are playing
>            nice and using the semaphore too, or else we're hosed. */
> 
>         get_some_kind_of_semaphore();

try flock() on the /sys/blah/blah/ directory.  That should keep userspace happy.  
I think it only takes a small sysfs patch to make this work (or it might work
today, don't remember, sorry...)

Or look into using configfs instead.

thanks,

greg k-h

Re: 2.6: how do I this in sysfs?

[gcoady]

On Mon, 29 Aug 2005 12:24:18 -0500, "Miller, Mike (OS Dev)" <Mike.Miller@hp.com> wrote:

>
>> This is after my minimal sas transport class, please also 
>> read the thread about it on linux-scsi
>> 
>In the referenced code for using sysfs, there only appear to be methods
>for reading attributes.  How about if we want to cause a command to
>get written out to the hardware?   Do we do something like this?
>
>        /* get a semaphore keep everyone else out while we're working,
>           and hope like hell that all the other processes are playing
>           nice and using the semaphore too, or else we're hosed. */
>
[...]
>        release_some_kind_of_semaphore();
>
>I'm not suggesting that the above is a good idea.  I don't have a good
>idea about how to do this.

Take a look at hwmon drivers, it is nowhere near so bad as you think.

Grant.

Re: 2.6: how do I this in sysfs?

[Christoph Hellwig]

> > typedef struct _CSMI_SAS_IDENTIFY {
> >    __u8  bDeviceType;
> >    __u8  bRestricted;
> >    __u8  bInitiatorPortProtocol;
> >    __u8  bTargetPortProtocol;
> >    __u8  bRestricted2[8];
> >    __u8  bSASAddress[8];
> >    __u8  bPhyIdentifier;
> >    __u8  bSignalClass;
> >    __u8  bReserved[6];
> > } CSMI_SAS_IDENTIFY,
> >   *PCSMI_SAS_IDENTIFY;

please compare this with struct sas_identify in
include/linux/scsi_transport_sas.h and look at
drivers/scsi/scsi_transport_sas.c om how it's exposed.

> > typedef struct _CSMI_SAS_PHY_ENTITY {
> >    CSMI_SAS_IDENTIFY Identify;
> >    __u8  bPortIdentifier;
> >    __u8  bNegotiatedLinkRate;
> >    __u8  bMinimumLinkRate;
> >    __u8  bMaximumLinkRate;
> >    __u8  bPhyChangeCount;
> >    __u8  bAutoDiscover;
> >    __u8  bReserved[2];
> >    CSMI_SAS_IDENTIFY Attached;
> > } CSMI_SAS_PHY_ENTITY,
> >   *PCSMI_SAS_PHY_ENTITY;

and this one to struct sas_port_attrs.

This is after my minimal sas transport class, please also read the
thread about it on linux-scsi

Re: 2.6: how do I this in sysfs?

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]

On Thu, 2005-08-25 at 13:52 -0500, Miller, Mike (OS Dev) wrote:
> I've been asked to pass this on for some kind of clarification. 
> We have management apps requiring specific information from the Smart
> Array controller. We're trying to use sysfs to accomplish the task. An
> example of what we need to do is below. I'm sure some of you will
> recognize this as CSMI.
> The basic question is this: how do you pass complex data structures back
> and forth between user/kernelspace and still abide by the rules around
> sysfs like: one attribute per file, text files only, etc?

Wouldn't you be able to post these items in sysfs attributes in the SAS
transport layer, assuming the cciss driver used the SAS transport layer.
Then the LLDD would be responsible for retrieving/setting the attribute
using whatever method is appropriate (dma, request queues, etc). 

I was hoping to start work on adding SDI operations to Christoph
Hellwig's SAS transport layer sometime next week.  

Andrew

> 
> Thanks,
> mikem
> > 
> > We have a storage controller which has some features which 
> > Work more or less as follows, but are not really "regular i/o"
> > In the sense that they are used for configuration or 
> > management Of devices rather than being the primary purpose 
> > of the devices.
> > 
> > The host constructs a somewhat complex data buffer according 
> > to a predefined convention, And fills out certain parts of 
> > the buffer to formulate what could be a query, or perhaps 
> > configuration data.
> > It then constructs a command which includes scatter gather 
> > elements Which reference this data buffer, and writes the bus 
> > address of the Command to a register on the controller.
> > 
> > The controller reads the command and data buffer from host 
> > memory, And DMAs the results of the query into the same data 
> > buffer, and issues An interrupt to the host.  So there's a 
> > bidirectional transfer Of data to/from the data buffer.
> > 
> > For example, one the data buffers the controller understands 
> > looks like what's below:
> > 
> > User applications need to be able to use this interface to 
> > talk To the controller.  What's the recommended way to 
> > implement such An interface?
> > 
> > // CC_CSMI_SAS_GET_PHY_INFO
> > typedef struct _COMMAND_HEADER {
> >    __u32 IOControllerNumber;
> > 	__u32 Length;
> > 	__u32 ReturnCode;
> > 	__u32 Timeout;
> > 	__u16 Direction;
> > } COMMAND_HEADER, *PCOMMAND_HEADER;
> > 
> > typedef struct _CSMI_SAS_IDENTIFY {
> >    __u8  bDeviceType;
> >    __u8  bRestricted;
> >    __u8  bInitiatorPortProtocol;
> >    __u8  bTargetPortProtocol;
> >    __u8  bRestricted2[8];
> >    __u8  bSASAddress[8];
> >    __u8  bPhyIdentifier;
> >    __u8  bSignalClass;
> >    __u8  bReserved[6];
> > } CSMI_SAS_IDENTIFY,
> >   *PCSMI_SAS_IDENTIFY;
> > 
> > typedef struct _CSMI_SAS_PHY_ENTITY {
> >    CSMI_SAS_IDENTIFY Identify;
> >    __u8  bPortIdentifier;
> >    __u8  bNegotiatedLinkRate;
> >    __u8  bMinimumLinkRate;
> >    __u8  bMaximumLinkRate;
> >    __u8  bPhyChangeCount;
> >    __u8  bAutoDiscover;
> >    __u8  bReserved[2];
> >    CSMI_SAS_IDENTIFY Attached;
> > } CSMI_SAS_PHY_ENTITY,
> >   *PCSMI_SAS_PHY_ENTITY;
> > 
> > typedef struct _CSMI_SAS_PHY_INFO {
> >    __u8  bNumberOfPhys;
> >    __u8  bReserved[3];
> >    CSMI_SAS_PHY_ENTITY Phy[32];
> > } CSMI_SAS_PHY_INFO,
> >   *PCSMI_SAS_PHY_INFO;
> > 
> > typedef struct _CSMI_SAS_PHY_INFO_BUFFER {
> >    COMMAND_HEADER IoctlHeader;
> >    CSMI_SAS_PHY_INFO Information;
> > } CSMI_SAS_PHY_INFO_BUFFER,
> >   *PCSMI_SAS_PHY_INFO_BUFFER;
> > 
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

2.6: how do I this in sysfs?

[Miller, Mike (OS Dev)]

I've been asked to pass this on for some kind of clarification. 
We have management apps requiring specific information from the Smart
Array controller. We're trying to use sysfs to accomplish the task. An
example of what we need to do is below. I'm sure some of you will
recognize this as CSMI.
The basic question is this: how do you pass complex data structures back
and forth between user/kernelspace and still abide by the rules around
sysfs like: one attribute per file, text files only, etc?

Thanks,
mikem
> 
> We have a storage controller which has some features which 
> Work more or less as follows, but are not really "regular i/o"
> In the sense that they are used for configuration or 
> management Of devices rather than being the primary purpose 
> of the devices.
> 
> The host constructs a somewhat complex data buffer according 
> to a predefined convention, And fills out certain parts of 
> the buffer to formulate what could be a query, or perhaps 
> configuration data.
> It then constructs a command which includes scatter gather 
> elements Which reference this data buffer, and writes the bus 
> address of the Command to a register on the controller.
> 
> The controller reads the command and data buffer from host 
> memory, And DMAs the results of the query into the same data 
> buffer, and issues An interrupt to the host.  So there's a 
> bidirectional transfer Of data to/from the data buffer.
> 
> For example, one the data buffers the controller understands 
> looks like what's below:
> 
> User applications need to be able to use this interface to 
> talk To the controller.  What's the recommended way to 
> implement such An interface?
> 
> // CC_CSMI_SAS_GET_PHY_INFO
> typedef struct _COMMAND_HEADER {
>    __u32 IOControllerNumber;
> 	__u32 Length;
> 	__u32 ReturnCode;
> 	__u32 Timeout;
> 	__u16 Direction;
> } COMMAND_HEADER, *PCOMMAND_HEADER;
> 
> typedef struct _CSMI_SAS_IDENTIFY {
>    __u8  bDeviceType;
>    __u8  bRestricted;
>    __u8  bInitiatorPortProtocol;
>    __u8  bTargetPortProtocol;
>    __u8  bRestricted2[8];
>    __u8  bSASAddress[8];
>    __u8  bPhyIdentifier;
>    __u8  bSignalClass;
>    __u8  bReserved[6];
> } CSMI_SAS_IDENTIFY,
>   *PCSMI_SAS_IDENTIFY;
> 
> typedef struct _CSMI_SAS_PHY_ENTITY {
>    CSMI_SAS_IDENTIFY Identify;
>    __u8  bPortIdentifier;
>    __u8  bNegotiatedLinkRate;
>    __u8  bMinimumLinkRate;
>    __u8  bMaximumLinkRate;
>    __u8  bPhyChangeCount;
>    __u8  bAutoDiscover;
>    __u8  bReserved[2];
>    CSMI_SAS_IDENTIFY Attached;
> } CSMI_SAS_PHY_ENTITY,
>   *PCSMI_SAS_PHY_ENTITY;
> 
> typedef struct _CSMI_SAS_PHY_INFO {
>    __u8  bNumberOfPhys;
>    __u8  bReserved[3];
>    CSMI_SAS_PHY_ENTITY Phy[32];
> } CSMI_SAS_PHY_INFO,
>   *PCSMI_SAS_PHY_INFO;
> 
> typedef struct _CSMI_SAS_PHY_INFO_BUFFER {
>    COMMAND_HEADER IoctlHeader;
>    CSMI_SAS_PHY_INFO Information;
> } CSMI_SAS_PHY_INFO_BUFFER,
>   *PCSMI_SAS_PHY_INFO_BUFFER;
>