[Info-vax] QIO Writes to a mailbox

[Bob Koehler]

In article <4ebb0b02$0$20027$c3e8da3$92d0a893 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> 
> There are generally 2 write option codes. IO$M_WRITEVBLK and another one
> whone nomenclature escapes me at the moment. Would those made a formal
> "documented" behaviour with regards to garanteed copying of the user
> buffer into a driver/device buffer during the SYS$QIO ?

   IO$_WRITEVBLK, IO$_WRITELBLK, and IO$_WRITEPBLK?  The difference
   is virtual, logical, and physical.  For a disk all three of these
   are different, and two of them require privilege.  For a terminal,
   they are all the same.  The difference is in the complexity of what
   a "file" might mean on the device.

   They have no affect on when $QIO does something.

> 
> Consider TCPIP. When you write data, you are not garanteed that this
> data goes out in its own packet. It may be combined with some previously
> issued writes or may wait until there are other writes made. Doesn't
> that behaviour pretty much require that the driver make copies of the
> data in its internal buffers so that you can then reuse your own buffer
> to issue subsequent writes ? (which allows the driver to then combine
> writes to make larger more efficient TCP packets) ?

   Some I/O interfaces are buffered, but _when_ the data is copied from
   the user's buffer to a system buffer is not pat of a documented API.
   There are kernel routines that do this copy, and in a lot of device 
   drivers they are called via FDT routine processing, which happens before
   $QIO returns.  But that is not guaranteed.  The driver writer can do
   other things.  An ACP can get involved.  Make no bets on anything not
   specified in the API documentation.