Hi, On Sun, Apr 10, 2011 at 10:41:23PM +0200, Thomas Schmitt wrote:
> 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. You could try whether ps2ps does any good... > Do i get it right that device_get_status() is on the other side of > the RPC interface ? (Seen from a user process.) You mean the implementation? Yes, that would be server-side, i.e. with the current driver framework within Mach. > If so: is there a chance to transfer a new struct through the existing > RPC of device_get_status() ? Well, In my understanding, device_get_status()/device_set_status() are very much like ioctl(), i.e. you can use them to add all kinds of device-specific functions without creating a new system call. (Which is less elegant, but easier to integrate.) > 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'm sure you do have the necessary skills -- the question is rather whether you are willing to spend considerable time digging into Hurd internals :-) > I am open for cooperation and also for doing some slave work. Not sure what you mean by "slave work"? I'm certainly willing to mentor you on the Hurd-specific aspects as well as I can; but I won't promise anything more... -antrik-