🚀 go-pugleaf

In article <1992Dec16.113301.977@cmkrnl.com>, jeh@cmkrnl.com writes:
> Are you happy with the $QIO system service?  [...]

p.s. -- I have my own ideas, but I'm going to hold off posting them for a 
while; I don't want to slant the discussion in the beginning. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh

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?
>	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
>Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
>Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com

Jamie,

	What an interesting question.  The way I see it, you have essentially
two ways of building an I/O interface: the way VMS/RSX do it and the way
UNIX/Ada/CP/M (I haven't studied MS-DOS or Windows NT or MVS closely enough
to decide which catagories they go into).  With VMS/RSX, you have a mechanism
by which an interrupt can be safely delivered to the process, while UNIX
and Ada really don't - you build tasks or threads which block until I/O is
completed.
	I assume that you are planning on building an O/S which can support
any language: C, Ada, FORTRAN, COBOL, Pascal, etc.  If you are building an
O/S which is oriented to a specific langauge, such as UCSD Pascal, Ada, or
Modula-2 then you have a simpler problem - don't bother providing any
functionality not supported by the semantics of the language.

	There is another aspect to the question which I just thought of.  One
of the characteristics of VMS which has always struck me is that number of
datastructures which get passed either by reference or by descriptor (VMS
is the only environment I know of which uses descriptors).  There are some
advantages and disadvantages of building a complicated data structure: the
overhead of stuffing the answers into the data blocks and then pulling them
out on the other side of the call.  Would it be easier to simply have long
argument lists?  It certainly seems more reliable to build the data structures
because the compiler can do some checking for you (for example, attempting to
stuff a 32 bit constant into a 16 bit space), and the compiler can keep track
of placing things in the right place.

	Jamie, why do you ask?

Jeff Silverman, Boeing Commercial Airplane

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

Re my prev post: I am assuming that *ALL* mem allocation is done by PAL code
and standard memory listheads, so the OS can allocate user address space
no probs, and de-allocate if needed.

~Paul

>> zrepachol  <zrepachol@cc.curtin.edu.au> writes:

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

Just some random thoughts on this idea.

If I understand correctly you want to avoid having to explicitly check
for an $QIO read completion (using event flags, ASTs, whatever) and
just enter a PFW state if you try to read the data before it is ready.

You want to issue the $QIO, do something else for a while, and when
you have nothing else useful to do try to read the data without having
to do any special check. This allows more overlap of computation than
a $QIOW.

I am not sure that a `low-level' system call needs to add the overhead
of a PFW state instead of the usual LEF state for this purpose. At the
(deterministic) place where you first try to read the data you just
need to insert a $WAIT on the event flag. There is a trade-off between
simplicity, efficiency, and flexibility here. $QIOW is even simpler
than your scheme, but less efficient in overlapping IO and
computation. The current $QIO is more flexible than your scheme, you
can check whether the IO has completed without having to wait if it
isn't, you can let it interrupt you when it is complete so you don't
have to poll it, etc., and $WAITing on an event flag is probably
cheaper than handling a page fault (albeit a soft one).

Finally, some of the functionality you want is provided by just
mapping the file into virtual memory. In fact, by mapping in the file,
and unmapping each page when you are done with it you have almost
exactly what you are requesting, don't you?

	-Tony-

In article <1992Dec16.113301.977@cmkrnl.com>, jeh@cmkrnl.com writes:
> 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 something else?

I like some of the stuff done in the AS/400. 
Although at a certain level I/O in any machine becomes a kludge.

In article <ADK.92Dec22012216@ds2.sun13.SCRI.FSU.EDU>, adk@sun13.SCRI.FSU.EDU (Tony Kennedy) writes:
>>> zrepachol  <zrepachol@cc.curtin.edu.au> writes:
> 
>    zrepachol> The change I would make is to buffer handling. On a read
>    zrepachol> the OS would do what ever needs to be done to dump the
>    zrepachol> data into mem, then fills in a pointer and size block
>    zrepachol> and maps the lot to your address space. By trapping the
>    zrepachol> page fault on a not yet mapped buffer pointer, the page
>    zrepachol> fault code can put the PC into a wait state till IO
>    zrepachol> completion clears the page fault condition. This would
>    zrepachol> enable atomic asyncronous IO from the user code view.
> 
> Just some random thoughts on this idea.
> 
> If I understand correctly you want to avoid having to explicitly check
> for an $QIO read completion (using event flags, ASTs, whatever) and
> just enter a PFW state if you try to read the data before it is ready.

Since it is inherent in my idea, that you don't know the address of the
read buffer, we trap the reference to the buffer pointer.

> 
> You want to issue the $QIO, do something else for a while, and when
> you have nothing else useful to do try to read the data without having
> to do any special check. This allows more overlap of computation than
> a $QIOW.

Yep, but we don't need to use a LEF, and we patch the hole of a QIOW with
no event flag.

> 
> I am not sure that a `low-level' system call needs to add the overhead
> of a PFW state instead of the usual LEF state for this purpose. At the

No Lef to WAIT for.

> (deterministic) place where you first try to read the data you just
> need to insert a $WAIT on the event flag. There is a trade-off between
> simplicity, efficiency, and flexibility here. $QIOW is even simpler
> than your scheme, but less efficient in overlapping IO and

Can't see why. As soon as the data is in and mapped, you become COM.

> computation. The current $QIO is more flexible than your scheme, you
> can check whether the IO has completed without having to wait if it

Point a PROBER at the BP to seen if we are done yet.

> isn't, you can let it interrupt you when it is complete so you don't
> have to poll it, etc., and $WAITing on an event flag is probably
> cheaper than handling a page fault (albeit a soft one).
> 

Note that there is no 'real' pagefault. We unmap the BP page so you can't get
at it before we are done, there by diving into the black-hole page.
Yes, we do need to map a heap of pages, but you can page now or page before
when you alloced the buffer. This scheme means we only PF the IOd pages, EVEN
if the IO is LARGER than you expected! No more buffer overflow, unless
the buffer is bigger than free memory. ( hey, a NEW 'buy more' reason... The
saleks will love it. :-) )

> Finally, some of the functionality you want is provided by just
> mapping the file into virtual memory. In fact, by mapping in the file,
> and unmapping each page when you are done with it you have almost
> exactly what you are requesting, don't you?
> 

How do I map a mailbox, net, tape, or tty?

~Paul