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

[olafBuddenhagen]

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-