To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: INETD                                                             


On Tue, 5 Nov 96 05:16:14 GM Guy Harrison <test@swampd wrote: 
>
>Here's a possible solution. Ronald mentioned a Supexec() type 
>function. While I see no reason to enforce superstate it has given me 
>an alternative suggestion ...

I did not mean that supervisor state should be enforced, but that use of
the patched basepage value should be limited in time, to lessen the risk
of conflicting usage needs, just as supervisor state should be limited.

If this sort of ownership control is to be legalized it would be better
to implement some kind of flag system preventing any other routine from
interfering while such an operation is under way.  Instead all routines
(incl TOS) that wish to do so must wait (loop or bypass) until the former
operation has been completed.


>Ovlexec(basepage,function,args ...)
>
>[ horrible name! ]
>
>For the duration of 'function' which has 'args' passed to it, the 
>process is known as 'basepage'.

That was sort of what I had in mind, but I suggest this function also handles
the flag I mentioned above, so that any reentrant calls (eg: from interrupts)
to the function exit with error until the first caller exits (flag reset).
The OS should also 'TAS' that flag when it wants to alter the pointer, and loop
until the pointer is 'free', and then update all stuff for its task switches,
whereafter it again resets the flag.

Thus this flag means "task data is being updated", and whenever any code gets
a positive value on 'TAS' of this flag it means the data is fully valid and
no one else (not even OS) will change it until the flag is cleared.
This flag implementation would allow fully reentrant and even interrupt driven
use of this feature (though interrupts should bypass rather than loop).

In fact, this protective flag is more important than the function, since it
guarantees completion of the needed operations before anyone else interferes.
The function simply ensures that entry and exit operations are made properly,
so that the system is not disturbed simply by a badly written program which
forgets to restore entry values.


>Thus, a process which loads an overlay can pass either its own 
>basepage or the overlay's basepage, effectively deciding which of them 
>owns any system resources brought into play.

Yes, but that is not all !
Since INETD is planned as an ACC, it may not legally own RAM, nor can it
legally Pexec any children of its own.  This is where we need the ability
to transfer both kinds of ownership to a TSR, which this scheme also allows.

All that is needed for this is that we know the basepage of a TSR, which could
be any TSR at all for all we care, but should be STIKTSR for dependability.
So STIKTSR needs to put it's basepage address into the STiK cookie structure.
Until this is done we can easily simulate it by using a dummy TSR which only
creates a cookie of its own with its basepage address as the cookie value.

That is what I use for my ACC-loader, and since that part is entirely my
own (unlike some other parts) I can donate it for STiK use immediately.
Cookie name = "Stuf",  value = &basepage.
This TSR will then be the 'official' owner of all INETD stuff, so that the
OS can't complain about an ACC owning things it isn't supposed to.

NB: If we want to release any files/RAM blocks at rez changes, it will be
    necessary to add system links for this, since TSR's are allowed to keep
    what they own on these occasions (unlike ACCs).  But doing so is NOT
    the best way in this case, because it really isn't needed if we add
    some simple housekeeping code to the TSR. 
    (My ACC loader has to release all stuff, so this code isn't in yet.)

    Then INETD.ACC can register each transferred ownership in a linked list,
    which will remain intact and waiting when INETD.ACC reloads after a rez
    change.  In fact this method could be used to preserve any data the ACC
    needs, to take up where it left off after a rez change.


>We would use Pexec(3) to load the overlay.
>Ovlexec() to invoke functions within it.
>Pexec(4) to a Pterm() to terminate the overlay. This would probably be 
>required to allow MiNT and MagiC to tidy up as the initial Ovlexec() 
>might require some rudimentary Pexec(4) processing to add the overlay 
>into the active process list.

I think so too, but experiments should clarify whether this is needed.


>I can see this being generic enough to appeal to Eric and Andreas, and 
>not too complex to prevent patches being written, whilst being simple 
>enough to implement on standard Gem also.

Yes, unless either of them has conflicting plans for that pointer...

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
