Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

me:
> > [...] my favorite candidate among the files in my CVS copy.
Samuel Thibault:
> CVS Copy?  The CVS repository is outdated. Which documentation advised
> you to check it out?

I have to guess a bit. But it looks like
  http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Helping-Out
in its node
  
http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Basic-CVS-Usage
shows an example that brought me to "Hurd Hacking Guide"
  http://www.gnu.org/software/hurd/hacking-guide/hhg.html
where
  http://www.gnu.org/software/hurd/hacking-guide/hhg.html#Requirements
says
"
  4. The sources of Hurd and GNU Mach are also useful:
     mkdir ~/hurd-cvs
     cd ~/hurd-cvs/
     cvs -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd \
         co hurd
     cvs -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd \
         co -r gnumach-1-branch gnumach
"

> git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git

Will get a new copy.

----------------------------------------------------------------------------

> > [my description of buffer needs of a pair of device_set_status() and
> >  device_get_status() for a SCSI transaction.]

> That advises into defining another RPC.
> [...] it looks a bit ugly to me.

The idea about device_get_status() was mainly based on the assumption of
an existing RPC transport between userspace and kernel.
This assumption is not valid any more.


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

Actually, Blu-Ray works best if fed with 64 kB per WRITE command.
The drives i know do not enable full speed streaming mode if the
chunks are smaller.
Old cdrecord has problems with some DVD drives which it tries to feed
with 62 kB per write. So alignment to 32 kB is very desirable for DVD.
growisofs and my own stuff do it so.

So a large transaction size should be a design goal, although it might
work with smaller sizes on many DVD drives and on BD.
Even if the kernel is restricted to smaller sizes now, the interface
should allow larger ones.


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.
Samuel Thibault:
> It'll probably be hard to express the SCSI commands he needs that way.

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.

A single system call as in Linux, FreeBSD, or Solaris would be
preferrable from the userspace programmer's view:
  ioctl(d->fd, SG_IO, &s);
  cam_send_ccb(d->cam, ccb);
  ioctl(d->fd, USCSICMD, &cgc);
On the other hand, there is a lot of ugly code surrounding these calls
in the libburn system adapters. A five-step would not make it much worse.

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


> > 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.


----------------------------------------------------------------------------

> > [...] i could not spot a function device_get_status() outside
> > toplevel directory gnumach. (Where is the RPC stub of the function ?
> It's generated from the Mach headers during libc build.

Oh. That explains a lot.


> > What files in the Hurd image should i backup and be ready to re-install
> > after i made it unbootable ?
> Just the kernel, since it's only the kernel that you will have to
> replace.

Now that i know, it seems obvious. :))

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.

----------------------------------------------------------------------------

Have a nice day :)

Thomas