Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

me, Tue, 06 Sep 2011 15:56:30 +0200:
> > I now assume linux/dev/glue/block.c is executed in a translator.

Olaf Buddenhagen, Tue, 6 Sep 2011 18:16:42 +0200:
> What makes you think so? I'm pretty sure we already said that currently
> the drivers are in Mach itself

I learned this yesterday from Samuel.

Your mail did not reach me until this morning.
(Obviously stuck in sky.local from 06 Sep 2011 18:16:16 +0200 to
 07 Sep 2011 09:59:26 +0200)

--------------------------------------------------------------------------
So this sub thread is probably obsoleted by the insight that a new
RPC would be the most desirable approach.
Nevertheless, i want to answer the question about multiple simultaneous
transactions:

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

For the purpose of burning, drives should be used exclusively
(which is not easy to enforce on Linux).
But there can be more than one drive working at the same time.
My Linux workstation currently has five of them.

So the multi-call solution would need a transaction state buffer per
drive, at least.
If exclusivity cannot be enforced, then there should better be a
state buffer per drive and per using process.


> [shudder]

Yeah.

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

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

Further: my scruples about RPC transmission size which i mentioned in my
mail of yesterday (06 Sep 2011 18:32:55 +0200) are obviously already
answered in an older mail:
==========================================================================
Date: Fri, 13 May 2011 22:42:09 +0200
From: Samuel Thibault <samuel.thibault@gnu.org>
==========================================================================
Thomas Schmitt, le Mon 09 May 2011 12:57:21 +0200, a écrit :
> A potential problem is that scsi_ioctl_send_command() is restricted
> to transfer MAX_BUF = PAGE_SIZE payload bytes.
> I could not spot the definition of PAGE_SIZE yet.

Page size on i386 is 4KiB.

[...]

> I am unable to determine whether this limit also applies to scsi_do_cmd()
> in hurd/gnumach/linux/src/drivers/scsi/scsi.c  which seems to do the
> transaction work.

It seems to be only 24bit limited.

[...]

I actually belive we can try to increase
MAX_BUF.  PAGE_SIZE looks like an arbitrary limit here.  The userland
buffer is allowed to cross page boundaries already, so I don't see what
could break when increasing MAX_BUF.

Samuel
=========================================================================


So everything seems to point towards a new RPC and increasing the
transaction size of scsi_ioctl_send_command().


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

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

Thanks for this info.
Currently it looks as if i still have a long way to go until the first
compile run happens.

Thank you all for your patience.


Have a nice day :)

Thomas