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
