From: Alan Cox <alan@llwyncelyn.cymru>
To: David O'Shea <dcoshea@gmail.com>
Cc: linux-8086@vger.kernel.org
Subject: Re: Memory issues and USB support?
Date: Mon, 5 Jun 2017 15:41:16 +0100 [thread overview]
Message-ID: <20170605154116.1f317011@llwyncelyn.cymru> (raw)
In-Reply-To: <CAN0DjM1gjA4n=dL6wy2jy5-npTCuB3XrxVRJGV1yFMX7Dsw2BQ@mail.gmail.com>
> 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?
The 8086 has no concept of page faults at all. The bigger limit is that
for small mode you've only got 64K offsets from each segment register.
The moment you try and deal with more than 64K data it gets ugly. More
than 64K code is ugly but slightly less so.
In the Linux 8086 case the big problem is the kernel stack for each
process comes from that 64K. Original Unix on the PDP-11 instead was able
to bank in and out a chunk of memory and put all the kernel stack and
per-process data that no other process needed in that chunk ('the uarea').
8086 doesn't have the MMU facilities for that but it does have the option
of using rep movs to block move such an area in and out on a task switch.
> 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?
Not a lot no. Most of this comes in with later processors.
The 286 has the 16bit segment limits but supports a protected mode (and
ELKS can use this in its most basic form), but any large applications
would need a rather different compiler and a load of kernel pieces to
support local descriptor table modification (as well as being really slow
when handling large stuff).
The 386 added 32bit mode and page basd protection.
Alan
next prev parent reply other threads:[~2017-06-05 14:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-04 13:55 Memory issues and USB support? David O'Shea
2017-06-05 14:41 ` Alan Cox [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-03-19 6:02 Derek Johansen
2017-03-19 13:57 ` Jody Bruchon
2017-03-19 14:27 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170605154116.1f317011@llwyncelyn.cymru \
--to=alan@llwyncelyn.cymru \
--cc=dcoshea@gmail.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).