Syscall (was: Re: [MiNT] DATE/TIME cookies)

[Konrad Kokoszkiewicz <draco@mi.com.pl>]

> Anyway, since the whole problem would go away if it was OK to call _some_
> OS functions from an interrupt, and it would be very good in general to
> cut down on the _immense_ system call penalty under MiNT, why don't we
> try to do something about that?

We are trying.
 
> For something as simple as gettime(), there should be no reentrancy or
> interrupt call problem at all (no global data is modified), so it's 'only'
> necessary to get rid of the MiNT 'baggage'.

Yes, see below.

> IIRC, MiNT saves the process state, copies stack parameters to an internal
> system stack, etc on almost every single OS call. IMO, this should only be
> done when it's absolutely necessary.

Actually, the only important stuff in MiNT that prevents reentrancy is the
syscall handler (hooked onto trap #1, #13 and #14). And it indeed does
things as you described. And it already has been optimized to get rid of
ugly vector swapping. And (yet once more) I didn't say it is the final
optimization. However, it is better to do it everything in subsequent
steps than rewrite the whole handler at once just to get a non-working
system or (worse) working, but unstable.

As you pointed out, saving the entire context may be not always necessary.
Moreover, in some circumstances may be not desired at all: for example,
when the trap call comes from the inside of MiNT kernel (which currently
is not the case, because calling MiNT from MiNT is illegal for now).

Also, one of things I dislike very much there is the operation of copying
(physically) the parameters from the user stack to the supervisor stack.
The only problem avoiding this is that particular MiNT functions are
written in C and it implies parameters on stack. Since it is supervisor
mode, it is supervisor stack.

I see no reasonable way (for now) to avoid that. Of course, we could let
MiNT use user stack as supervisor one (move.l usp,sp or something) and
access all stacked parameters less or more directly, but this may demand
that user processes will have to allocate more stack space for themselves
- i.e. to satisfy both their requirements and the kernels.

Maybe I am missing something, but this made me think that the Motorolas
concept of a separate user and supervisor stack is a bit silly.

Another thing is the reentrancy. Since we're using TOS BIOS and XBIOS,
no full reentrancy is possible, if a BIOS/XBIOS function isn't completely
replaced by MiNT. So, the reentrancy issue may currently apply only to the
DOS part of the system, *if* TOSFS is not used.

However, I must admit, that there's some code there (in the syscall.spp)
that could be removed if MiNT's DOS would be reentrant. I started to work
on it just last Saturday, let me some time, it will be done sooner or
later.

With some work, having a reentrant DOS, it can be done that some kernel
functions could be preempted, which (perhaps) would make the system
running more smoothly.

> If a process must block it's of course necessary to save state information,
> but then don't do it until it's clear that a block is actually inevitable.

Actually this is done in BIOS. The DOS always goes for full syscall
sequence.

> Using a table with an entry per function (as Trapatch does) it's very
> simple to direct all calls to an appropriate handler, which may or may not
> do an 'expansive' OS entry.

Sure.
 
> Well, I think I'd better take a look at the MiNT internals again before
> I get too deeply into this.

Yes, would be very nice.

--
Konrad M.Kokoszkiewicz
|mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
|http://www.obta.uw.edu.pl/~draco/
|http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.