Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

> http://www.gnu.org/software/hurd/microkernel/mach/mig/documentation.html

Actually it is the link labeld "ps" on that page which delivers
a description of the language:
  http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps
My oldish gv has problems with page navigation in
  http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.ps
but it seems of lesser interest for now.

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.


> > Naming conventions:
> > How to name the function ?  device_transact_scsi() ?

> It shouldn't include "scsi" since it could be useful to other
> conditions.

> > Does that mean, that all instances of struct device_emulation_ops
> > have to be augmented by a function pointer ?

> Yes, although for all the structs which are not of interest to you, you
> can simply put NULL there.

It is quite a problem that the new call currently makes sense only to
SCSI CD drives. (Because only there i know how to get Scsi_Device.)
It will nevertheless be a property of block.c and there will be a
counterpart in the structs of e.g. net.c.

Under this premise, the new method needs to become more generic, so that
it can make some sense with the other block devices and with devices of
other modules.


Olaf Buddenhagen wrote 9 Sep 2011 00:45:44 +0200:
> 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.


Under Samuel's premise, i currently think about something like

  routine device_transact_native(
             device          : device_t;
       in    function_code   : unsigned int;
       in    in_len          : size_t;
       in    in_data         : unsigned char;
       out   out_len         : size_t;
       out   out_data        : unsigned char
  );

I would expect that drivers for any device are able to encode their
orders in a character array and to receive the outcome in another one.
We should probably partition the number space of function_code
for the various families and types of devices. 

Olaf's premise would give an opportunity to define a more specific
interface, of course.

Which way to go ? 


-------------------------------------------------------------------

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.

-------------------------------------------------------------------


Have a nice day :)

Thomas