Hi all, I'm new here, and I'm just about to send a bunch of emails about various things, but I will probably quieten down fairly quickly, so don't worry :) > From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> > Date: Sun, 19 Mar 2017 14:27:45 +0000 > > ... > > On an 8086 the other option is to support EMM boards. That allows you up > to 4MB or so of which 64K at a time is visible in a fixed memory window - > that's actually ideal for ELKS but fiddly for memory management as any > application that's got split code/data and can be over 64K will need to > be arranged so only half of it lives in EMM space. Apologies if I'm getting things extremely muddled up here, but I take it that since you're not in protected mode, you don't get to have page faults which give the kernel the opportunity to make the code/data the application wants available, and instead the application is going to have to be aware of the fact that some of it is not necessarily directly addressable without asking the kernel first? I always knew about EMS having a 64KB page window from the DOS days, but https://en.wikipedia.org/wiki/Expanded_memory says that in LIM EMS 4.0 "any 16 KB region in lower RAM [could] be mapped to expanded memory", which makes it sound to me like the ELKS kernel could at least map in a process's memory when it's about to run it and then unmap it when it switches to another process? 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? Just curious - not planning to try my hand at implementing any of that, sorry! Thanks in advance, 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
