Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

Samuel Thibault wrote:
> AIUI it's device_get_status() in linux/dev/glue/block.c for the linux
> IDE & SCSI devices.

Yeah. That is my favorite candidate among the files in my CVS copy.
But i was uncertain to which side of the RPC gap this belongs,
because i could not spot a function device_get_status() outside
toplevel directory gnumach. (Where is the RPC stub of the function ?
Where does dev_status_t get transmitted ? ...)

My next planned topic to learn is to get an overview about the
relation of libburn's userspace, kernel and servers:
I now assume linux/dev/glue/block.c is executed in a translator.
But which one ? (What is the model relation of server and translator ?)


> However, I realize that the status parameter of the device_get_status
> RPC is out only, not inout, so device_get_status alone can not provide
> complete support.

Ouch.

> One way would be to use a set/get pair.

This would mean to send the SCSI command and possible payload data
by device_set_status() and to buffer the reply until device_get_status()
is called to fetch it.
The reply would consist of 18 to 252 bytes of Sense Data (e.g. error reply)
and as much payload as 
  gnumach/linux/src/drivers/scsi/scsi_ioctl.c:scsi_ioctl_send_command()
would be willing to transact in its parameter "buffer". (MAX_BUF ?
Wasn't there some bad news with MAX_BUF being smaller than 32 kB,
the natural transaction size for DVD ?)

This reply buffering would have to happen individually for each
struct block_data that may be handed to scsi_ioctl_send_command() as
parameter "void *d".i
Is there a suitably persistent relation between instances of
struct block_data and the instance of device_t device in userspace ?


> Another way
> would be to define a new device_command RPC, and extend the
> device_emulation_ops structure with it.

Currently it seems appealing to have one that calls quite directly
scsi_ioctl_send_command() .
(I hope that would fulfill my wishes. Assuming that the appropriate
 translators use this call for their SCSI transactions, too.)


-------------------------------------------------------------------------
(About development cycle:)
> > Even if i had a detailed plan of what to code where, i still lack of
> > an idea how the development cycle for a kernel change would look like.

> Simply rebuild gnumach and reboot with it.

What files in the Hurd image should i backup and be ready to re-install
after i made it unbootable ?


-------------------------------------------------------------------------
(My ssh botching:)
> > Except i cannot find out why logging in from the hosting system by
> >   ssh -p5555 localhost
> > demands a password.
> Maybe check the permissions on $HOME,
> $HOME/.ssh and $HOME/.ssh/authorized_keys.

Indeed i forgot to apply chmod go-rwx to ~/.ssh after creating it.
Now it works.

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


Have a nice day :)

Thomas