Hi,
iansjack wrote:
But why shouldn't it be possible? What exactly leads you to think that a 32-bit kernel can't launch and run 64-bit programs? After all, a 64-bit kernel has no problem running 32-bit applications.
In long mode all interrupt handlers have to be 64 bit (even when you're running 32-bit code). You could have 64-bit "stubs" that switch to 32-bit to work around that, but right from the start "100% pure 32-bit kernel" is impossible.
Next, what happens when you're running a 64-bit application and it causes a page fault? 32-bit code can't even access the highest bits of CR2 to find out what the problem was, and the paging structures are different anyway. You'd have to rewrite the page fault handler for 64-bit (and can't just have a 64-bit stub that calls old 32-bit code). You'd also need to rewrite the lower level parts of virtual memory management.
Then; everything that used any virtual address from user-space or returned virtual addresses to user-space will have to be changed to handle a 64-bit virtual addresses; including whatever structures you're using to keep track of "in progress" transfers to/from disk (swap, memory mapped files) and file IO and networking, etc. If you want to be able to debug and profile 64-bit applications then that includes the breakpoint and debugging exception handlers plus everything else that could be involved (performance monitoring counter code, last branch recording, etc).
Most of the scheduler would be fine; but whatever you're using to save the previous task's state and load the new task's state is going to have to handle "64-bit state". This might mean that (e.g.) if a 64-bit application blocks or something you switch to old 32-bit kernel code to decide which task to switch to, then switch to 64-bit code to do the actual task switch.
If it was a micro-kernel, then "minimum changes to support 64-bit applications" means you probably need to rewrite half the micro-kernel just to end up with something that resembles the Flying Spaghetti Monster.
Cheers,
Brendan