Re: [address@hidden: Interface for SCSI transactions ?]

[Samuel Thibault]

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