Thomas Schmitt, le Sun 10 Apr 2011 22:41:23 +0200, a écrit : > > > So what is Hurd's attitude towards a driver that occupies 2.5 MB > > > of memory when idle and might expand much more on the job ? > > > Is it worth to continue thinking about xorriso-in-the-system ? > > > > Not a problem in a Hurdish mind. The stuff can be split in low-level > > driver which just does the SCSI commands and a daemon which does the big > > stuff, run as mere user. > > The low-level driver would be the SCSI transaction call. > > Do i get it right that device_get_status() is on the other side > of the RPC interface ? (Seen from a user process.)
Yes. > And that there needs to be defined a new RPC to reach a new call > device_transact_command() ? Yes. > If so: is there a chance to transfer a new struct through the > existing RPC of device_get_status() ? > (Probably not, i expect.) device_get_status transports an variable-size array of integers, no more, no less. > Honestly spoken, i do not feel apt to cope with the task of wiring > the SCSI transaction to userspace. > I probably could design the struct and derive the scsi transaction call > from scsi_ioctl_send_command(). (Copying from Linux might help, too.) > But i am already clueless about the task to assert that the device > handle of device_transact_command() is suitable for scsi_do_cmd(). > > So it looks as if we have to stop here until a better skilled person > appears who is interested in enabling burner drive operation. I'll let it to anybody who has time for this. Samuel
