Supervisor mode & multitasking

[Konrad Kokoszkiewicz <draco@piwo.bl.pg.gda.pl>]

Hi,

yesterday night I've compiled and tested a special version of the kernel
with no restriction to switch tasks only in user mode. MiNTOS setup works
more or less stable with that, though I noticed some problems: e.g. my
uname (supplied with PL 6) didn't want to display the hostname. It may be
a lib problem (getenv or sprintf or printf). I didn't do more extensive
tests - i have no spare filesystem for that.

However, the GEM is another story. As it was quite likely, removing the
user-mode-only restriction causes all sort of crap troubles and bad
crashes. The reason is quite straightforward: any time the kernel is
called, a flag called in_kernel is set to avoid preemption in the kernel
code. This also allows to avoid preemption in the ROM code, because the
ROM for BIOS, GEMDOS and some XBIOS is called exclusively by the MiNT. The
rest of XBIOS functions, as well as VDI and AES, however, is NOT called
via MiNT kernel. Thus, the in_kernel variable remains unset and the
scheduler doesn't know it shouldn't preempt the task being inside ROM VDI.

For the XBIOS code, the solution is quite simple: just to patch all xbios
calls into MiNT (by the way, Yves, Falcon XBIOS functions aren't defined
in the library!!! :( ). This is also possible for VDI, but not for the
AES, as the AES is mainly not present in the system while MiNT gets
loaded. Hopefully, patching VDI vector will be enough, as I quite don't
think the AES really gets an advantage from the fact that supervisor can't
be preempted. All sort of video effects I've observed under the test
kernel, seemed to be done by the VDI.

Nevertheless, this may be done, but it doesn't guarantee 100% stability. 
As I know from someone else (hi, Anders ;)), BadMood developers need
multitasking in supervisor to make the program networkable.  As I looked
at the Super() and Supexec() system calls, they can't be fixed easily to
do that, besides, it might broke compatibility with existing software (you
never know which program takes advantage of the fact that there's no
multitasking in supermode). So, the best solution for now is, in my
opinion, to add the THIRD system call referring to the supervisor mode. I
konw that it looks paranoid (three calls of the same purpose, one of them
is quite not necessary, but I think the one is GEMDOS Super()), so
explanation goes:

1) Keeping Super() and Supexec() has an advantagoe of compatibility with
   old software
2) new call should do nothing special, just return in supervisor mode
   instead of user. Before it returns it should setup the scheduler so
   the calling task will be forced to be preempted even if its in
   supervisor.
3) calling it again should switch the task back to the user mode (i.e.
   the call called from supervisor returns in user and the other way 
   around).

I think that for now we may stay with such a limitation, that only one
supervisor may be running in multitasking at a time (i.e. the rest of
tasks has to be usermode).

Comments?

Aha, I forgot. I added some sort of singlemode to the kernel. As I know
Gryf requested that for Thing, here goes the proper call:

	r = Ssystem(MTASK_OFF, NULL, NULL);

This locks the scheduler on the current task (SLICE count never expires).
r return s a zero on success or EACCDN otherwise (the function is
root-only). The call:

	r = Ssystem(MTASK_ON, NULL, NULL);

enables multitasking again. Proper constant definitions will be supplied
with the kernel (ssystem.h) and mintlib pl 48.

I also thought about expanding Pexec() for that - i.e. launch program in
single mode. Comments?

Gtx,

Konrad M.Kokoszkiewicz
mail:draco@bl.pg.gda.pl
http://www.orient.uw.edu.pl/~conradus/

** Quem Iuppiter vult perdere, dementat prius.
*******************************************************
** Kogo Jowisz chce zgubic, temu wpierw rozum odbiera.