Re: Interface for SCSI transactions ?

[olafBuddenhagen]

Hi,

On Tue, Sep 06, 2011 at 06:32:55PM +0200, Thomas Schmitt wrote:

> Would it be a problem to transport MAX_BUF + 252 bytes through a RPC ?

Not sure what MAX_BUF is here; but there are no limitations on the
amount of data transferred in an RPC :-)

> Olaf Buddenhagen:

> > Well, if we need to go for a multi-RPC approach, I'd suggest doing
> > it *properly*, i.e. using get_status/set_status only for actual
> > control information, and pass the data with read/write calls.

> I could imagine a five-step transaction if there is no other way to
> get a large payload through RPC:
> 
> 1: Userspace would open the transaction by sending the SCSI command
> through device_set_status(), 2: pass possible payload data by write(),
> 3: trigger the actual transaction by another device_set_status(), 4:
> wait for the end of the transaction in device_get_status() which would
> return the SCSI Sense Data and the number of reply payload bytes, 5:
> finally fetch the reply bytes by read() if there are any.

Indeed this is more or less what I was thinking of :-)

> So the main argument against the five-step is the complexity in the
> kernel, where fat transaction states would have to be implemented.

Agreed.

> > > Currently it seems appealing to have one [RPC] that calls quite
> > > directly scsi_ioctl_send_command() .
> 
> > That's probably the most correct way.
> 
> But looks quite out of my personal reach for now.

It should be much easier to implement than the five-step thing described
above... The biggest difficulty is probably finding the various places
where handling for the new call needs to be added througout the device
emulation chain. Apart from that, adding a new RPC is surprisingly easy
:-)

> To my excuse i can only state that all info about Hurd emphasizes
> servers and translators. SCSI itself matches this model well. So it
> did not come to me that the situation is not much different from a
> Linux kernel (except the quite invisible RPC'ing). I rather expected
> something like one translator per SCSI bus.

Well, as I already mentioned once, Mach itself is actually not very
Hurdish... It was not designed for the needs of the Hurd; rather, the
Hurd was built around the preexisting Mach.

Of course the situation will change for SCSI handling, once we have
userspace disk drivers :-)

-antrik-