> A simple solution for the kernel stacks is to use the user stack in > kernel mode, this is: > > DS = ES = Kernel segment > SS = User data segment. DS != SS requires far pointers. Think about char x[40]; char *p = x; p now points to SS:something which is not the same as DS:something. > Of course, this leads to problems. And the current kernel will require > very careful inspection and corrections. But I think this is doable by > enforcing some simple rules. > > What do you think? It doesn't work because you can take the address of a stack based object, and not only that the compiler will do so itself internally when generating code. So to fix the stack you need a per process store for stacks and to do something on task switch akin to switch: while nothing else to run idle(); if we are now the only/next thing to run (usual case) return; save our kernel stack somewhere (asm code to set ds: es: rep movs restore) change task load new kernel stack (ditto) Note btw you can't use prefixes with rep movs on 8086 because there is a CPU errata that a restarted rep instruction sometimes forgets the prefixes! The fancier version is to hash processes by stack (so say slots 1,5,9,13 use stack 0, 2,6,10,14, stack 1 .. etc). You have to keep the stack you use for a given process constant but you can attempt to make sure that usually a switch doesn't cause a copy in or out of stacks. It turns out that on a small single user machine in particular the number of task switches between tasks is miniscule. From the shell you switch once to the app, once back to wait(), then back to the app and probably don't switch again to anything but idle state unless the user changes console, exits the program or runs a sub process. Now and then cron or similar will briefly juggle things around but that's about it. Fuzix uses the simple algorithm above on many platforms for the same reason and it work extremely well even on a 4MHz Z80. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
