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
