[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interface for SCSI transactions ?

From: Thomas Schmitt
Subject: Re: Interface for SCSI transactions ?
Date: Tue, 06 Sep 2011 15:56:30 +0200


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.


> 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 
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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]