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

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

> > 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...
> 
> I guess you would need a local kernel stack for each process, then.

Yes, that's how I do it in my realtime kernel. In that case I only need
64 bytes of stack space (the kernel itself doesn't do anything more
complicated than message passing and is written in 100% assemly (around
1500 lines)), though, so it doesn't really matter much.
Being a realtime kernel, it's not supposed to keep anyone (interrupt or
process) waiting for longer than absolutely necessary, so it should be
possible to preempt the kernel most of the time. The sometimes necessary
mutual exclusion is handled by turning off all interrupts around small
critical sections.

For an OS like MiNT, I don't see any reason to make it possible to preempt
the kernel at all (but support for 'realtimish' processes would be nice).
None of the system calls should take too long to execute (well, at least
not if the device drivers were interrupt driven where appropriate) and
there are no realtime guarantees, anyway.

It might be nice to be able to signal semaphores and such from within
interrupt routines (in my kernel any non-blocking call is OK) under MiNT.
I think that would require the kernel to have complete control over the
interrupt, though, and you'd need to disable interrupts around critical
sections in the kernel.
IIRC, there is currently a way to let signal handlers know about interrupts,
which is probably enough for non-device driver stuff.

-- 
  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)