From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: Why kernel size limitations? Date: Wed, 03 Mar 2004 00:50:43 +0000 Sender: linux-8086-owner@vger.kernel.org Message-ID: <40452BE3.3020104@cowlark.com> References: <20040302214035.52238.qmail@web11707.mail.yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20040302214035.52238.qmail@web11707.mail.yahoo.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-8086@vger.kernel.org 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]