From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: Memory issues and USB support? (and OpenWatcom) Date: Sun, 11 Jun 2017 15:54:36 +0100 Message-ID: <20170611155436.541a5398@llwyncelyn.cymru> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: David O'Shea Cc: linux-8086@vger.kernel.org > That kind of leads me to something else I wanted to ask about: I take > it the requirement to use small mode is because of the bcc compiler? Moving to large code isn't a problem, but large data means far pointers and that means a huge slowdown in performance. Instead ELKS has some facilities to allow things like disk cache to be in a different segment. For userspace large models also mean you can't do swapping until you have 286 protected mode. > > In the Linux 8086 case the big problem is the kernel stack for each > > process comes from that 64K. > > On entry to the kernel, couldn't one change SS:SP to point to some > other memory area? It looks like the parameters to system calls are > in registers rather than on the stack. Is it just a case of not > having done this extra work of managing more bits of memory yet, or is > there an architectural limitation here? SS and DS have to be the same in small and tiny mode. A syscall switches to the kernel code and data so the kernel has 64K of data to play with. It uses a load of it on kernel stacks it could avoid at a small cost on context switches. If that were fixed there would be plenty of kernel data space. > I was kind of thinking that a process whose pages are in EMS are > unlikely to get corrupted by a process running off the end of an > array. I realise that I shouldn't have used the term "memory > protection" though! It's less likely one would be scribbled on, but in fact if you give a 16bit process 64K code and 64K data it has to corrupt segment registers to scribble outside of its space and that makes it more reliable than you might expect. Alan