[MiNT] analysing syscall.spp

[Joerg_Westheide@su.maus.de (Jörg Westheide)]

Hi Konrad!

KK>In this case it doesn't hurt anything as long as they're atomic.
Yes, but that has to be ensured

KK>Anyways, Malloc() or Mxalloc() rather :-) cannot wrap back to trap
KK>handler, so it doesnt matter if they modify globals or not.
Well, I thought that one aim is to make the MINT-GEMDOS reentrant and
callable from interrupts (where possible)

KK>Contrary, a Fopen() can wrap back if a filesystem driver decides to
KK>call a trap.
I don't like think that idea because we then will never be able to remove the
rentrance check.
Wasn't there an interface for these drivers to call MiNT directly? If so
these calls are no problem. Programs hooked in the GEMDOS chain before MiNT
currently should be no problem (as long as they do not do GEMDOS calls via
trap#1 again). For calls to programs behind MINT one could introduce a new
call which bases on trap_1_emu. But that means that you have to decide if
this system extension has to be started before or after MiNT... :-/

KK>Also Fread() can "wrap" if it is done in the background and another
KK>process decides to call the system in the meantime. If both calls go
KK>down to the same BIOS function a mess is quite likely to occur.
well this could possibly be avoided by some(?) semaphores...

Bye

                Joerg