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

[Johan Klockars <rand@cd.chalmers.se>]

> > > Maybe it is (ridiculous), but as I am thinking about it, designing a
> > > multitasking OS would be easier, if user stack space could be used for
> > > kernel requirements. Though it would be a memory waste without any doubt.
> > 
> > I don't see how you want to make a stable system by overwriting user data
> > space with stack space needed by tke kernel in error situations. Better to
> > have a large-enough kernel stack, IMHO.
> 
> Who said "overwrite"? The stack would just have been appropriately bigger
> (that's what i meant for memory waste). If MiNT has 8k stack, the user
> stack space bigger by 8k would satisfy both user process and the system.

While I agree that it can be easier not to have a special kernel stack
at all (I don't have one in my own realtime kernel), I don't really think
it's such a good idea.
For example, that would mean that much of what the kernel put on the stack
during the system call execution would be accessible to an interested user
program afterwards, which might be a security problem.

Another potential problem is that you don't really have any control over
the amount of stack space used by device drivers. With the current process
stack setup methods this could mean a stack overrun. A kernel stack
could be handled differently and (using the MMU) be extended if needed.

> Anyways, the reality is we have separate stacks and I don't think we
> should discuss such facts ("there's no argument agains a fact" as old

Is there really something in MiNT that _relies_ on the kernel having
its own stack?
(No, I'm still not suggesting we do away with it.)


Having a kernel stack does pose another problem, though, which hasn't
been mentioned yet - a kernel call must run to completion before another
can be made.
If it was possible to preempt the kernel, another thread could attempt to
call it too, and that 'copy' of the kernel couldn't use the same stack...
So, another stack would be needed, and we'd end up with something similar
to the terrible way parts of TOS does things (reentrancy to three levels).
(Note that this doesn't cause any problems for reentering functions from
 within the kernel itself.)

Currently this is not a problem in MiNT since preemption is disabled when
running in supervisor mode, which the kernel always does. AFAICR, it has
always been the intention to get rid of this 'limitation' for processes,
though, and then some other kind of mutual exclusion method will be needed
for the kernel.
Still, multiple simultaneous kernel calls could of course be handled by
making the kernel multi-threaded.  ;-)

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)