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

[Thomas Schmitt]

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 scdbackup@gmx.net or publicly
via bug-xorriso@gnu.org .


Have a nice day :)

Thomas