Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

current state of MIG definition (stop me when i go astray):

  routine device_transact_native(
             device          : device_t;
       in    function_code   : unsigned int;
       in    in_data         : ^ array[] of unsigned char;
       out   out_data        : ^ array[] of unsigned char
       );

With C prototype for ds_routines.c:

  io_return_t
  ds_device_transact_native(
      device_t                dev,
      unsigned int            function_code,
      unsigned char           *in_data,
      mach_msg_type_number_t  in_len,
      unsigned char           *out_data,
      mach_msg_type_number_t  out_len);

and for block.c:

  static io_return_t
  device_transact_native(
      void                    *d,
      unsigned int            function_code,
      unsigned char           *in_data,
      mach_msg_type_number_t  in_len,
      unsigned char           *out_data,
      mach_msg_type_number_t  out_len);

d will be fed by dev->emul_data of ds_device_transact_native().
It will be interpreted as (struct block_data *).


There will be functions in kernel and userspace which serialize and
de-serialize parameter structs.
One of these serializer families will be specific to SCSI devices.
Either function_code or a magic number at the start of the serialized
data shall assert that serializer and de-serializer match.

Within block.c there may be other serializer families for
device_transact_native() with other function_code values.
The same with other classes if they implement device_transact_native().


Some reasoning:

------------------------------------------------------------------------
Olaf Buddenhagen:
> I just saw that device_open() also has other
> parameters without a direction... So I have to admit quite frankly that
> I don't know what this really means.

mig.ps page 6 explains that "in" is default, and that the first parameter
without a direction specifier depicts the port by default.
There is RequestPort to explicitely mark one parameter as target port.

But i have difficulties to understand how the C prototype of a
variable length byte array would look.
I would like to use
     in      in_data      : ^ array[] of unsigned char;

Page 3 of mig.ps says:
 "For variable length arrays an additional count parameter is generated
  to specify how much of the array is actually being used."

So do i have to feed this by two C variables ?
And what type has the additionally generated count parameter ?

Learning by example, i read in gnumach/include/device/device.defs
  routine device_set_status(
                device          : device_t;
        in      flavor          : dev_flavor_t;
        in      status          : dev_status_t
        );
and in 
  io_return_t
  ds_device_set_status (device_t dev,
                        dev_flavor_t flavor,
                        dev_status_t status,
                        mach_msg_type_number_t status_count)
  
How come (mach_msg_type_number_t) ?
Where was this assigned to mach_port_array_t resp. to init_port_set ?

gnumach/include/mach/message.h:
  typedef natural_t  mach_msg_type_number_t;
gnumach/i386/include/mach/i386/vm_types.h:
  typedef unsigned int  natural_t;  

So for now: (mach_msg_type_number_t) with semantics of (unsigned int).
(It still would be nice to understand why ...)

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

Further i learned that MIG assumes structs to have the same memory layout
on sender and receiver of the RPC. Only their sizes get specified.
Page 3 of mig.ps:
 "There is no way to specify the fields of a C structure to MIG."
(This looks to me much like a design flaw for a distributed operating
 system.)

So MIG transmitted structs are inherently of fixed size.
But i want variable size.

Serialized structs in byte arrays seem to be the only way to get this,
although they require four serializer/de-serializer functions for each
implementation of device_transact_native().

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

Olaf Buddenhagen:
> Hurray, bikeshedding time! ;-)

First we have to choose the maximum number of wheels per vehicle.


Samuel Thibault:
> > > device_emulation_ops
me:
> > Does that mean, that all instances of struct device_emulation_ops have
> > to be augmented by a function pointer ?
Olaf Buddenhagen:
> Yes, I think so.

Do you agree that this pushes the plan towards a generic shed for
the bikes of women, men, children, and dogs ?
Prepared for three wheels although the dogs have no bike yet and
the kiddies use their smartphones for simulating a bike ride ?

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


Have a nice day :)

Thomas