Hi Alan, all, On Tue, Jun 6, 2017 at 12:11 AM, Alan Cox <alan@llwyncelyn.cymru> wrote: > The bigger limit is that > for small mode you've only got 64K offsets from each segment register. 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? I saw various mentions of looking at using OpenWatcom in the past (e.g. http://www.spinics.net/lists/linux-8086/msg00417.html), and I didn't see these reach any showstoppers or anyone saying it was a terrible idea, nor success. Is moving to OpenWatcom something that would be welcome, so long as it was truly an improvement (and didn't require performing compiles on DOS :) )? > 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? Apologies if any of the above are FAQs! >> As it is, with LIM EMS >> 3.2, even if you can only map in a single 64KB page at a time, you >> could at least do that for some of their memory. I guess you also get >> some memory protection from this, right? > > Not a lot no. Most of this comes in with later processors. 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! Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
