Re: Interface for SCSI transactions ?

[Samuel Thibault]

Thomas Schmitt, le Tue 06 Sep 2011 15:56:30 +0200, a écrit :
> 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.

CVS Copy?  The CVS repository is outdated. Which documentation advised
you to check it out? The gnumach source is in git since some time
already:

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

> But i was uncertain to which side of the RPC gap this belongs,

It's the server side.

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

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

No, it's in the kernel ATM.

But since it's an RPC, it could be in a translator, e.g. a DDE
translator running Linux drivers.

> But which one ? (What is the model relation of server and translator ?)

Anything can be a server, it simply has to receive and reply to the RPC
messages on a port.

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

Yes.

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

That advises into defining another RPC.

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

It would have to be defined, and it looks a bit ugly to me.

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

That's probably the most correct way.

> -------------------------------------------------------------------------
> (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 ?

Just the kernel, since it's only the kernel that you will have to
replace.

Samuel