16-bit code and L4
Valery V. Sedletski
_valerius at mail.ru
Wed Jun 20 16:01:33 CEST 2007
On Wed, 20 Jun 2007 13:42:57 +0200, Marcus Voelp wrote:
>> 2) 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).
>> 3) 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
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
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?
Thanks for answering my questions,
More information about the l4-hackers