[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [MiNT] MetaDOS compatibility broken (fwd)



Hi!

I'm forwarding some interesting remarks from a private discussion between
Ronald Andersson and myself.

Jo Even Skarstein

> -----Original Message-----
> From:	dlanor@oden.se [SMTP:dlanor@oden.se]
> Sent:	Thursday, June 24, 1999 10:10 PM
> To:	Jo-Even.Skarstein@gjensidige.no
> Subject:	RE: [MiNT] MetaDOS compatibility broken (fwd)
> 
> Here follows a fairly comprehensive description of what I consider to be
> the
> necessary 'linking' for what I see as TOS compatibility, together with a
> new
> method to implement that in MiNT, such that no MiNT capabilities are lost
> or
> in any way downgraded. If you think this would interest MiNT people, you
> are
> naturally free to forward it to them:
> 
> 1: When a file or drive function known to MiNT, but addressing a drive
> that is
>    not known to internal drivers (or loaded XFS drivers) then MiNT should
> pass
>    control to some underlying dispatcher.  As MiNT does implement drivers
> for
>    all drives known to normal TOS, it will never be normal TOS that deals
> with
>    such an access, but will always be some other dispatcher that has
> logged in
>    to the XBRA chain between TOS and MiNT.  Naturally MiNT may first check
> if
>    any bit in the system variable '_drvbits' ($4C2) has been set that
> matches
>    the specified drive, as it is not necessary to 'link down' otherwise.
> That
>    will make MiNT work fine with BetaDOS (or other MetaDOS) and yet retain
> all
>    positive qualities for all MiNT-level drivers, including error
> reporting
>    capability for access attempts to drives not implemented by any
> dispatcher.
> 
> 2: When a gemdos function is not known to MiNT at all, it should always
> pass
>    the call down some underlying dispatcher that may have implemented it.
> If
>    such a call reaches the TOS gemdos dispatcher, then the only result
> will
>    be the return of an E_INVFN error value, which is identical to what
> MiNT
>    too must return for such cases.  The only problem with this is if
> another
>    similar call is made by another task, switched to while TOS gemdos work
>    is in progress.  A solution for all such problems is given further
> below.
>    The 'linking down' for unknown functions will allow other dispatchers,
>    such as the one of BetaDOS, to add new functions (eg: MagiC 6 type
> SLBs)
>    to maximize compatibility with other systems of the TOS platform,
> without
>    requiring all such things to be incorporated into MiNT.
> 
> 3: Bios and Xbios functions should always be 'passed down', when they
> concern
>    anything that MiNT can not deal with completely.  There are many TOS
> clone
>    machines in existence, and it is necessary to allow patch programs to
> fix
>    compatibility problems. MiNT can never be expected to do it all
> internally
>    as the family of TOS machines is constantly growing.  Another important
>    aspect is that they often have conflicting needs, and trying to include
>    code for all those needs in the kernel would make it ridiculously
> large.
> 
> One of the problems that the MiNT developers must have meant is that entry
> in
> the function dispatchers of TOS does not allow any preemptive
> taskswitching to
> be done, as that could lead to reentrancy of those TOS dispatchers, which
> can
> bomb the system.  Yet, for the MiNT dispatcher to block task switching
> between
> the time it 'links down' and the return from such linking could lead to
> static
> task handling if the function in question is a file or drive operation
> that is
> implemented by an 'intermediate' gemdos dispatcher which needs a lot of
> time to
> complete that particular work.
> 
> The generic solution to this problem is to make an extra dispatcher
> especially
> to protect from such things.  It should be installed immediately 'above'
> the
> GEMDOS, XBIOS, and BIOS dispatchers of TOS itself, and should simply
> increment
> a protection counter before passing the call to TOS, and should decrement
> that
> same counter again at return from the TOS call.  MiNT can then use the
> counter
> value as an indicator for ongoing activity that makes task switching
> hazardous,
> and should only preempt when the counter is zero, indicating that no work
> is in
> progress by the original TOS dispatchers.
> 
> You might ask "why a counter ?", and "why not just a flag to set or clear
> ?",
> and the answer is that such flags do not work for functions that
> themselves
> call BIOS or XBIOS functions.  Even in original TOS those dispatchers do
> have
> a limited form of reentrancy, which is used in many GEMDOS functions and
> even
> in a few BIOS and XBIOS functions.  But the number of levels is quite
> limited,
> so a simple counter can easily render this safe.
> 
> This method, of implementing extra 'protective' dispatchers, will limit
> the 
> amount of time that preemption needs to be disabled for completion of work
> in the original TOS dispatcher.  And that work will normally be very fast,
> as none of it should concern file or drive access, as such work should
> always
> be done by superior dispatchers in the XBRA chains.
> 
> Alternatively, the 'protective' dispatcher may even take harsher measures,
> so
> as to refuse any access at all to the 'bottom' level of TOS GEMDOS, but I
> do
> not think it is advisable to do that for BIOS or XBIOS, as a lot of things
> are
> done there that it should not be necessary for MiNT to duplicate. For
> example,
> MiNT would then have to duplicate screen hardware control functions
> compatibly
> to all existing TOS machines, which is quite ridiculous, as several need
> to
> have differing implementations of the same functions, and quite large
> ones...
> 
> The 'protective' dispatchers can easily be installed by MiNT digging
> through
> the XBRA chains to find the first entry which does not use XBRA.  That may
> or
> may not be the actual TOS dispatcher, of course, but that does not matter
> as
> there is no reason to maintain any compatibility with vector benders that
> do
> not use XBRA properly.  Such are to be considered garbage anyway.