From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 21-DEC-1992 14:47:59.81
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: Call for partly-baked ideas:  $QIO replacement?/extention

In article <1992Dec16.113301.977@cmkrnl.com>, jeh@cmkrnl.com writes:
> Are you happy with the $QIO system service?  If you were building a new O/S
> from scratch, would you make the "basic I/O call" that's available for
> non-privileged programs look like $QIO, or like something else?  If the
 latter,
> what?  If you could specify a new I/O interface to supplement $QIO in VMS,
 what
> would it look like?
>

The change ?I would make is to buffer handling. On a read the OS would do what
ever needs to be done to dump the data into mem, then fills in a pointer and
size block and maps the lot to your address space. By trapping the page fault
on a not yet mapped buffer pointer, the page fault code can put the PC into
a wait state till IO completion clears the page fault condition. This would
enable atomic asyncronous IO from the user code view.

On write, the buffer would be un-mapped so as to trap scribbeling on the output
before it completed.

1. no more "how big do I need to make the buffer... well I'll double it to
   make sure..."

2. You can't access a half DMAed page. ( prob various option bits to turn this
   off, reuse buffers... )

3. Simple sysnc primative. Do IO, access buffer pointer *page fault*, thread
   stalls till IO completes

4. For async, AST address is valid, IO completion passes buffer pointer as
   ASyt parm.

5. You have done 1/2 the work for a *FAST* task/task--process/process IO
   system. Unmap, context switch, remap.


MANY loose ends here I realise... Will comptemplate over chrissy...

~Paul