On 06/02/2011 01:41 PM, Michael S. Tsirkin wrote:
Now to our problem:
As far as I can tell there are two input buffers in each request: sense
and data. Right?
If sense is fixed length, we can simply put it first, have device write
sense then data. This does not seem too limiting, if you want a lot of
flexibility sense length can be in device config. If we don't want to
limit ourselves to fixed length sense, we would have driver use two
heads for a request. This is possible but one needs to be careful in
the driver to make sure there's enough space for both requests. Maybe
add_bufs API to add multiple bufs might be a good idea here.
I should be on holiday today so I'll answer this quickly. Sounds like
we can converge, I'll put data at the end and define the length of sense
in the config: the device writes a default (defined by the spec to be
always 96) and the driver can modify it. The _single_ head would contain:
- read-only: command etc.
followed by:
- write-only: sense, status etc.
followed by:
- read-only: data to device
- write-only: data from device
IIUC, qemu only sees a bunch of read-only and write-only buffers. It
doesn't see the relative ordering of read-only vs. write-only. But it
knows the sizes of read-only and write-only data, so it can figure out
datain_size and dataout_size. sense_size is in the config, so neither
of the three needs to be in the request.
sense_len needs to stay, since any number of bytes can be written in the
sense buffer. The used-length field should be usable for
uni-directional commands, but I'm not sure about commands that have both
datain and dataout. I'll read the SCSI spec about it tomorrow.
Making qemu support arbitrarily partitioned buffers may require some
extra utility functions to work on iovecs, but nothing too complex. If
your patches already contain something like that, please dig them up so
I can avoid duplicate work!
Paolo
