Re: Interface for SCSI transactions ?

[olafBuddenhagen]

Hi,

On Tue, Sep 06, 2011 at 03:56:30PM +0200, Thomas Schmitt wrote:
> Samuel Thibault wrote:

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

The server side is generated during Mach build; the client side is
generated during libc build... Not sure which one you mean.

> I now assume linux/dev/glue/block.c is executed in a translator.

What makes you think so? I'm pretty sure we already said that currently
the drivers are in Mach itself -- although we want this to change in the
future...

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

A translator is any (server) process accessible through a node in the
filesystem tree. Almost all Hurd servers are translators.

Mach also offers a number of in-kernel servers for handling various RPCs
-- for example the device server (ds_) for handling device RPCs such as
device_get_status(). These are obviously not translators, as Mach
doesn't even know what a filesystem is :-)

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

Not sure what you mean here... Are you asking about a possible situation
where several requests are in flight simultaneously, i.e. set_status()
is invoked again (possibly by another processes) before the
corresponding get_status() call is done for the previous one?

IIRC the current implementation of the device handling can't handle
separate client sessions... So I fear the only way to associate possibly
overlappnig set_status()/get_status() pairs would be by explicitly
passing some handle... [shudder]

Sounds like one more reason for adding a specialised atomic RPC instead
:-)

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

Not sure what translators you mean here...

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

None... If you just copy the freshly built "gnumach" binary to /boot, it
won't overwrite the default kernel (which uses a different file name),
so you can choose which one to boot in GRUB :-)

(You can even leave out the copying, and instead boot the kernel
directly from the build tree... Though this might be a bit more
cumbersome to request in GRUB.)

-antrik-