Re: Interface for SCSI transactions ?

[olafBuddenhagen]

Hi,

On Mon, Sep 12, 2011 at 11:23:04PM +0200, Thomas Schmitt wrote:
> Olaf Buddenhagen wrote 9 Sep 2011 00:45:44 +0200:

> Now i am puzzling whether i shall try to describe a struct in MIG or
> whether i shall serialize and de-serialize to and from a byte array.

Unless there is some practical difficulty, I *strongly* suggest to
describe the individual struct members with MIG, rather than doing the
marshalling (serialisation) by hand.

This means the RPC will be really SCSI-specific. It is a bit ugly, as it
will add a meaningless entry for all other device classes; and it is not
consistent with the idea of device_get_status()/device_set_status()...
However, this is rather academic, as the transaction RPC isn't actually
likely ever to be used by anything else anyways. I'd favor sanity over
consistency in this case.

(Doing manual marshalling is extra effort; and it will have to change
again when moving to userspace drivers -- while using a proper hurdish
RPC from the setout means it can be directly reused for the userspace
driver interface.)

> > Defining special-purpose RPCs as we need them is The Right Way (TM).
> 
> I am willing to follow The Right Way (TM). But i cannot match this
> with the interface that Samuel tells me to use.

Well, I generally see a lot of merit in being consistent with existing
interfaces; but as I explained above, in this case I'm not convinced
that it's the best option... I hope Samuel will agree with the benefits
I pointed out -- or otherwise tell me why I'm wrong :-)

> I meanwhile assessed the newer SCSI transaction structure of Linux:

>   typedef struct sg_io_hdr { ... } sg_io_hdr_t; in <scsi/sg.h> 

> by checking its usage in libburn and in growisofs. It seems well
> suitable as paragon for in_data and out_data (resp.  for a more
> specific parameter struct under Olaf's premise).
> 
> I plan to assess the structs of FreeBSD CAM and Solaris uscsi during
> the next days. Then i'll write a summary and propose SCSI transaction
> parameters for a long-term Hurd interface. It's implementation will be
> based on the very sparse transaction struct in gnumach. But i believe
> the userspace interface should already now be wide enough to express
> what the other OSes can express.

Agreed. While I'm a strong proponent of the YAGNI principle, in this
case it's indeed pragmatic to use something based on the tried structure
from some popular modern system, so we can minimise Hurd-specific
effort.

-antrik-