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


On Thu, 7 Nov 1996 12:47:19  Peter Rottengatter <perot wrote: 
>
>On Wed, 6 Nov 1996, Ronald Andersson 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.
>> 
>> 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.
>
>For STiK wide operation (including clients), there is such a system : The 
>STiK API provides set_flag and clear_flag for semaphor purpose, we just 
>need to assign another bit.

But if such methods are to be legalized there is need for such a flag in OS,
so I'd prefer Guy's approach of an auto-installed OS extension that provides
the same functionality that may later be built into some of the newer systems.

This way STiK does not need to identify whether the OS has this built in or
not, but simply assumes that the functions are present.  Users can then simply
disable the auto-patch program when booting a future MiNT or MagiC, with STiK
never caring who supplies the functions.


>> 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.
>
>Surely may any ACC own RAM, it only needs to allocate it at boot time, so 
>that the desktop is the owner.

That is not entirely true, since even such RAM may sometimes be allocated as
owned by an auto-started application.  That is why 'Thing' has 'Thinwait' and
other alternative desktops also have needed similar utilities.
It is also why Atari never allowed Malloc by ACCs as legal.
(Although they used it themselves in Xcontrol, and did so in an erroneous way.)

All RAM needed must be allocated before calling 'appl_init' to avoid the risk
that a non-resident auto-APP is registered as owner.  This means that RAM size
needs to be a compilation constant if the normal startup module is to be used.
Thus any runtime allocation will require a replacement module to allocate RAM
safely.  (eg: Based on a user defined value in a config file)
(This is what Atari forgot when they made Xcontrol.)

Most of those problems simply disappear if the ACC is coded in assembler instead,
since this allows full control of the entire sequence of startup events.

But it is an unpleasant and unnecessary limitation to always have to grab the
maximum amount of RAM that might be needed.  Some users would hate that !!!
But if the method we've discussed is approved we don't have to do that.


>For this and Pexec the manipulation of the basepage pointer will help under
>single-TOS, with MagiC it is simply not required.

That is mainly true, but we do not want to write entirely different code for
these two cases, so it is best to find a way that works for both.
Also remember that ownership transfers are useful in other situations too,
which may come to be of equal importance under MagiC as well.


>Any ACC can determine whom it's at boot time allocated memory blocks 
>belong, and should enter this value into newly assigned blocks. This is 
>easier, and cleaner for the mentioned dependability.

Ok, but it should not enter that value directly in blocks.  That would assume
a specific Malloc implementation, which is completely illegal and will stay so.
We have absolutely no guarantee that either MagiC or MiNT will retain the usage
of current implementations in future ones as well.


>> 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.)
>
>No reason to care for this if my suggestion is followed.

Ok, but this means all communication dies at rez changes then,
so the entire STiK system is then reinitialized from scratch.
(Although STiKTSR needs to be told so by the reloaded INETD.)

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