Hi, > There's the "Documentation" link on this page which I believe has all > the links that exist.
I meanwhile downloaded machuse.ps which drives my gv to the edge of madness. It starts at page 20 and i can only go backwards page by page. Probably i should make 20 screenshots for reading them in sequence. > > 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.) And that there needs to be defined a new RPC to reach a new call device_transact_command() ? If so: is there a chance to transfer a new struct through the existing RPC of device_get_status() ? (Probably not, i expect.) 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. It will not be totally trivial to fulfill the other needs of libburn. E.g. how to list all CD capable drives. But the SCSI transaction call seems to be the crucial obstacle. I am open for cooperation and also for doing some slave work. Eventually contact me in private via scdbac...@gmx.net or publicly via bug-xorr...@gnu.org . Have a nice day :) Thomas
