Re: Kernel size over 64K: what is needed, how to implement?

[David Given <dg@cowlark.com>]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

On 17/02/12 18:20, Jody Bruchon wrote:
[...]
> * Support must be added to bcc/ld86 need to be able to use far pointers.
> * A file format must be specified that includes relocation tables for
> far pointers.
> * A loader stub must be added to the kernel to relocate its own far
> pointers at boot.
> * After this is done, support should be added to load userland
> executables this way too.

Far pointers are big, expensive and slow, and incredibly fiddly to deal
with --- it's not a flat 32-bit address space; consider that 0x00010000
and 0x00000010 address the same byte of memory, and that 0x0000ffff + 1
is not 0x00010000. This means that pointer arithmetic becomes painfully
non-trivial.

Adding far pointer support to userland executables also completely
scuppers the ability to move executables around in memory, as each one
gets tied to a particular set of segments. Which means no swap!

Alternative options are:

(a) move chunks of stuff out of the kernel and put it into userland
daemons. This means that each kernel or daemon can remain a small mode
executable. This is what Minix on 8086 and 286 did, and it was very
successful. This is particularly attractive for big, standalone modules
like filesystems or the TCP/IP stack; but the downside is that it's
rather un-Linux-like, as it will require a certain amount of kernel
reengineering.

(b) compromise, and use *medium* mode for the kernel. Medium mode
executables use 32 bit code pointers and 16 bit data pointers. The
advantage of this is that nobody does pointer arithmetic on function
pointers, so all the weird pointer normalisation issues go away. But
even though you can use as much code as you want, you're still limited
to 64kB of combined stack/data space.

Regarding C compilers --- has anyone ever tried Open Watcom? It claims
to support all these weird 8086 segmentation modes, and there is a Linux
version. It's also supposed to produce pretty decent code, which may
well be more compact than bcc's and so save crucial kernel space.  Never
touched it myself, though.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Never attribute to malice what can be adequately explained by
│ stupidity." --- Nick Diamos (Hanlon's Razor)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]