Hi, me: > > routine device_transact_native( Samuel Thibault: > Why "native"?
Because the transactions are of a genuine kind that is specified only for particular device types. I dug deeper in the existing code. It seems that my desired transaction applies only to these storage device types: - SCSI hard disk - SCSI CD-ROM - IDE/ATAPI CD-ROM (IDE disks do not use SCSI commands. SCSI tapes seem not have the properties of a classical block device as they are covered by SSC rather than SBC. With ATAPI tapes i expect the same.) Are there proposals for a better name which describes the general purpose ? (Reminder: It is so general because the method will occupy a slot in struct device_emulation_ops of all device classes.) There is another publicly visible name to decide: The function_code for my desired transaction type. Currently it is #define DEVICE_TRANSACT_NATIVE_SCSI_PKT 0x00010001 Other kinds of transaction to the same class or to other classes of devices would have public names like #define DEVICE_TRANSACT_NATIVE_... I did not look yet, how public Hurd macros names usually look like. (Those in the driver code are often short english words.) > > So do i have to feed this by two C variables ? > Mmm, I think the simplest way is to just rebuild the kernel with the new > RPC, and look at the generated prototype. I think the example of device_get_types() already confirms it. "^array[]" translates to a C pair of pointer and mach_msg_type_number_t. I am now collecting a sketch of code snippets which shall connect the RPC receiver function with the IDE and SCSI drivers. Desperation and optimism alternate in the usual way. Have a nice day :) Thomas
