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


On Thu, 7 Nov 96 08:42:36 GM Guy Harrison <test@swampd wrote: 
>
>  Ronald Andersson <dlanor@oden.se> wrote:-
>>
>>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.
>
>You may be right. It depends on how Eric and Andreas would want to 
>implement it. It may be easiest for them to treat it just like any 
>other process, or not. :-)

Unfortunately Peter reports that Andreas wants nothing to do with it...
Personally I think he misunderstood the intended usage though,
judging from the reasons he gave for refusing to approve.


>>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.
>
>The example I've done is (sort of) re-entrant and runs in user mode. 
>I've made up the rules as I've gone along. A functional implementation 
>may bear no resemble to it at all. Depends on Eric and Adreas again.

I actually meant that your model should be complemented with this flag
handling which would ensure that no conflicting usage could arise.


>The example for standard Gem can take advantage of the fact there 
>aren't going to be any more standard Gem's!

True, except that we already have accepted certain standards from the late
design phase of MultiTOS, which has influenced all the new AES authors.

In fact MagiC is the closest to a new standard we have, since it can run on
more systems than any other GEM-based OS.  But there are also the MiNT based
systems to consider, of which the current leader must be nAES, since most of
the other ones are still in a fairly early design phase, except Geneva which
unfortunately is partly based on outdated MTOS specifications.  Thus it is
not fully compatible with modern MiNT versions.


>Plus I decided that you 
>call it from user mode which excludes interrupts. You'll no doubt be 
>horrified by what I've done but I see no point in doing anything other 
>than convey the idea until we are sure it can be achieved.

Well, I _would_ disagree with user mode calls, and Andreas recommended that
we stick to super mode for such calls if we must use them in single-TOS even.
For MagiC he refused to agree, and he claimed it could not work with MiNT.

But since he also stated that STiK itself can't work with MiNT, I'd rather
try it out myself, because I know that the latter statement is mistaken.
I've made several new tests today just to make absolutely sure of it, and I
had no problems at all to make STiK work with MiNT + nAES.

I suppose he only tried with MultiTOS, which probably bombs for its own
personal reasons, having nothing to do with STiK.


>( and it takes me an age to write assembler )

I prefer it over all others, but then I started using it very early, having
only written a couple of ALGOL programs before that.  Later when I bought
my first personal computer (not a PC clone (they didn't exist)) I planned
to take up high-level programming rather than learn another ASM dialect.

Fortunately the BASIC for it was delayed in production, so I got my 6502
ASM grounding, and learned how easy it really is to learn new dialects
once you have learned a couple of them.  They do have a lot in common.

Now I do know some HL languages of course, but seldom prefer to use them.


>>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.
>
>That is the hope!

Was!  If Andreas sticks to that decision we can't do much about it.
We can still use the trick for single-TOS of course.


>>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.
>
>The relaxation of the usual acc memory restrictions will have a wide 
>appeal.

Yes, and though others may not want to call it legal, they still have
to agree that it does work in single-TOS, where restrictions are worst.


>>    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.
>
>I hadn't even considered rez changes!

Well, I think we have to, since it is a legal desktop operation, though STiK
usage naturally demands that no connection is open at such times unless data
is preserved for the subsequent reload of STIK.ACC (later INETD.ACC).

Peter considers such preservation an unnecessary complication, and he does
have a point of course, though I rather liked the idea myself.


>>>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...
>
>And there we have the 64,000 dollar question!!

Well, Andreas did not have any such plans at present, but refuses to tie his
hands by agreeing to keep this functional (which it is at present).  He did
suggest making some alternative ownership control available from the kernel
of MagiC, but that would be a completely MagiC-specific method.

Of course, if we can only get a similar method guaranteed to work for MiNT,
we can then tie them together with a common entry/exit interface.  This way
we can achieve the function we wanted, though this is internally implemented
as three separate methods. (One each for MagiC, Single-TOS, and MiNT)


At that stage I say we go ahead and make that auto-patch, thus adding a new
function 'behaving' precisely as the one we had already planned.
Thus all programs (not just STiK) can use it without testing for OS versions.

Precisely which function(s) we should implement depends on what alternative
method Andreas has in mind, and what we can use for MiNT.  For the latter
we still need to get in touch with Eric Smith of course.

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