Interrupts and exceptions use the kernel stack, not the user stack, so kernel entry point from the bootloader is valid.
Keean. On 12 Feb 2015 14:36, "Jonathan S. Shapiro" <[email protected]> wrote: > On Wed, Feb 11, 2015 at 10:59 AM, Keean Schupke <[email protected]> wrote: > >> There is only one entry point into the program. The others like interrupt >> vectors and exceptions are re-entry points. The main entry stack frame >> would still be there for all these re-entries, and only gets cleaned up on >> program exit, by which time all the interrupt and exception vectors must be >> cancelled if you don't want a horrible crash :-) >> > > Keean: > > I think you're joking here, but since it leads to something (very) mildly > interesting... > > What you say is actually not true in the EROS or Coyotos kernels. Yes, > there is an initial entry point where all of the pre-user-mode > initialization occurs. The end of that path is a call to > sched_dispatch_something(), which actually *does* exit the kernel, > effectively destroying the initial stack. The storage for that stack is > subsequently used as the stack space for CPU0. > > Once that dispatch occurs, there can be mulitple re-entry points into the > kernel, because many processors have more than one vector they may invoke. > We actually converge all of them back onto a single path. But the stack > context of main() is long gone by the time one of those gets reached. > > From a terminology perspective, I consider those interrupt vectors to be > entry points. > > You could certainly arrange things so that some assembler code appeases > the hardware and then invokes a closure, but that can be tricky in > practice. Interrupts do not tend to cooperate in concurrency regimes, which > makes GC quite difficult in a kernel. Because of the way Coyotos is > structured, I think we actually *could* GC in the kernel, but the kernel > proceeds by allocating all memory to itself and then never releases it, so > GC serves no purpose. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
