Re: Why kernel size limitations?

[David Given <dg@cowlark.com>]

Tommy McCabe wrote:
> I have been finding several errors recently during the
> ELKS kernel compilation. At first I thought it was the
> version of BCC I was using (0.16.15). I then realized
> what it really was: the System file wouldn't form if a
> certain segment of code was bigger than 65535 bytes-
> otherwise a program called ld86 returns an error
> message saying it's too big for 16 bits. This could be
> a bit of a problem, especially when more features are
> included into the kernel. Why is there this
> limitation? Even an 8088 is capable of handling code
> segments bigger than around 65KB.

I'm afraid that turns out not to be the case.

The 8086 and 8088 support several compilation models, depending on how 
many segments the program takes up. (I may be getting the names wrong.)

Tiny		single segment: cs=ds=ss. All pointers 16 bit.
Small		Two segments: cs gets one, ds=ss gets the other. All
			pointers 16 bit.
Medium		2+ segments: cs gets one, ss gets one, multiple ds.
			Code pointers 16 bit, data pointers 32 bit.
Large		2+ segments: ss=ds get one, multiple cs.
			Code pointers 32 bit, data pointers 16 bit.
Huge		Many segments. Multiple cs and ds.
			Code pointers 32 bit, data pointers 32 bit.

The ELKS kernel is compiled in small mode. So we're stuck with a maximum 
of 64kB of code and 64kB of data.

There are two things we can do to expand from here: hack the kernel to 
allow seperate modules to be loaded in addition segments, and call out 
to them as needed (which would work, would let us stick with 16 bit code 
pointers, but be a compilation nightmare), or to recompile the kernel in 
  large mode. To do this we need a compiler which supports large mode, 
which bcc doesn't. Plus it would cause a lot of problems because some 
but not all of our pointers would become 32 bits wide...

Yeah, this is a known problem. If you can think of a clean workaround, 
feel free to suggest one! There's currently more useful stuff in the 
ELKS tree than will fit in the kernel's code segment...

(My pet idea, back when I was actually working on ELKS, was to put in a 
streamlined user driver interface to allow the kernel to call out to 
user space for certain non-essential services. Sockets, for example. 
This would have the advantage that you could write the really nasty, 
complex drivers as ordinary processes, which would help debugging; plus, 
the kernel can swap them if needed. Unfortunately it would be a bit 
slow, and we'd end up reinventing Minix.)

-- 
[insert interesting .sig here]