On Wed, 20 Jun 2007 13:42:57 +0200, Marcus Voelp wrote:
Hi Valery,
- Must all the segment registers be CS == DS == ES == FS == GS == SS == FLAT in L4 usermode
programs (in Intel
architecture implementation)? Or, there exist a possibility to use segments other than FLAT?
Fiasco preserves some of these segments (e.g., GS to support thread local storage). However, unless OS/2 makes use of these segments in 32-bit mode there is no need to change these from a flat setting.
It seems, that OS/2 does not use GS (GS seems to be always == 0), at least, in application programs.
But, if the program contains 16-bit segments, there can be the need to execute 16-bit code in these segments. In OS/2, 16-bit protected mode segments can coexist with 32-bit flat segments. When 32-bit part of a program calls the 16-bit part, it comes through the thunk (assembler code, which converts 32-bits flat pointers into 16:16 pointers and passes control from 32-bit part to 16-bit one). So, during the passing through thunk, segment registers are loaded with 16-bit segment selector. So, there is a need in segments, other than flat (mostly, 16-bit ones).
- Is it possible to cause the L4 kernel to create 16-bit segment descriptor on Intel architecture?
What you are looking for is microkernel support for the virtual x86 mode.
But, V86 mode can help emulate Real mode. It is mostly useful for creating DOS emulator, but how can it help with creating 16-bit protected mode support? So, 16-bits != real mode (or I don't understand)
Unfortunately, only the old L4 assembler kernels supported this processor mode and these are no longer supported. If you really want to run the 16-bit code on bare metal (and not in something like qemu) you probably need to add support for VM86 into the kernel (e.g., by adding an architecture specific systemcall which executes some code in VM86 mode and which returns with any abnormalities to a 32-bit exception handler).
So, the V86 support can be implemented through architecture specific system call. And, probably, we need not only V86 support, but also a means to cause the L4 kernel to allocate GDT selector for 16-bit protected mode code support? So, the only way to execute 16-bit code (i.e., code in segmens with "16-bit" descriptor attribute) in L4 is to fork microkernel source code, adding custom changes?
Best regards
Marcus
-- Marcus V÷lp
Thanks for answering my questions, WBR, Valery