Re: Supervisor mode & multitasking

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

> > 1) BadMood, to run fast on Falcon, has to run in supervisor, because it
> > wants to utilize as many CPU power as possible.
> 
> No, that's not why.
> Under standard TOS, supervisor mode doesn't buy you anything and current

I know. I am not one of code wizards who believe that the CPU works faster
being in supervisor mode.

> The problem that the call would address is that some software need access
> to the hardware registers often and performance would go down drastically
> if Super/Supexec was needed every single time.
> In BAD MOOD the DSP is accessed frequently and that needs supervisor mode.

That's exactly what I meant.

> > do you think BadMood will be finished?
> 
> Now, don't be so negative.  ;-)

Esp. if now the develpoers have a possibility to look at Quake source code
and such stuff.

> > 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).
> 
> What would that gain us, apart from halfway supporting the kind of mutual
> exclusion that supervisor mode used to guarantee?

Less complex code for P_super() call. :) Well, I didn't code it yet, so
I have no idea about particular problems.  Perhaps it will be easy to
allow unlimited supervisor processes to be scheduled as well/

> > 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:
> 
> Since lots of people don't seem to like that, I think you need to add an
> on/off switch for that in mint.cnf. That way everybody could have it the
> way they like best.

Yes, I thought about this. May be done easily, but who prevents bad
programmers ffrom writing in the doc: "to run this program you'd have to
set SINGLEMODE=ON in MINT.CNF..." ?

> > I think it is a guaranteed system feature that there is no task
> > switching in supervisor mode. Why would you want to change that?
> 
> The way I recall it, this was claimed to be subject to change, but you
> may well be right.

Yes, the information that the rule titled "the supervisor doesn't
multitask" may go away, can be read in many places across the source
tree. I am very sorry to write that, because before I came to the MiNT
list, I thought that Julian Reschke, who wrote the Profibuch and was
generally considered well experienced specialist for Atari things, will
be more constructive. Now I see he generally tends to complain about every
change we discuss here and isn't very helpful either. Julian, please...
don't damage your legend for newbies. Your scandalic answer regarding a
skeleton XFS ("MiNT is full of examples...." while MiNT is over 1.2 MB of
source code!!!) I'll remember to the end of my life.

> Ideally, _no_ user rogram should ever be allowed into supervisor mode.
> If that is allowed, there's never going to be any way to stop a task
> from hanging the entire system. Memory protection doesn't help since
> it's easy to disable interrupts and then enter a loop. That could happen
> accidentaly as well as by design.

Ssystem() call and security levels were intended to help with it. When all
basic Unix software gets recompiled with a new MiNT Library, we all can
set SECURELEVEL=2 and this time no user process can call Supexec() or
Super(), if it wants to survive next second.

> > However, XBIOS restriction is delayed becayse MiNTLibs doesn't define any
> > Falcon XBIOS call. I'll be sitting on this next days, Yves, exspect a
> 
> Why would you need that? You said _all_ XBIOS functions should be protected,
> which would be easy enough to do with a TRAP handler.

Coz at the moment software linked with old mintlibs wants to use
Supexec().

> Wasn't the "single task" call supposed to be for tasks that simple can't
> deal with multitasking? 

Yes, it was supposed exactly for that.

So, I think it may be concluded like this:

P_super() will be added to allow supervisor tasks running in multitasking
when absolutely necessary. This call will be restricted to root and we
sort-of guarantee that it will be supported by future versions of MiNT.

MTASK_ON/OFF functions of Ssystem() call will be added to support backward
compatibility. They're also restricted to root, but usage of them is
strictly discouraged by anything but system software, like the desktop is. 
As they're designed to help for old and badly written software, it is not
guaranteed that these will be supported by future versions of MiNT. Also,
the root can switch them off on purpose using SINGLEMODE keyword in the
MINT.CNF file.

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.