[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.