* Re: Why kernel size limitations?
2004-03-02 21:40 Why kernel size limitations? Tommy McCabe
@ 2004-03-03 0:50 ` David Given
0 siblings, 0 replies; 2+ messages in thread
From: David Given @ 2004-03-03 0:50 UTC (permalink / raw)
To: linux-8086
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]
^ permalink raw reply [flat|nested] 2+ messages in thread