DragonFly BSD
DragonFly kernel List (threaded) for 2013-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Fwd: Selection of roadmap for i386 platform End-of-Life (EOL)


From: Tobias Weingartner <weingart@xxxxxxxxx>
Date: Wed, 1 May 2013 15:48:19 -0700

---------- Forwarded message ----------
From: Tobias Weingartner <weingart@tepid.org>
Date: Wed, May 1, 2013 at 3:47 PM
Subject: Re: Selection of roadmap for i386 platform End-of-Life (EOL)
To: "B. Estrade" <estrabd@gmail.com>


On Wed, May 1, 2013 at 11:55 AM, B. Estrade <estrabd@gmail.com> wrote:
>
> FWIW, FreeBSD and NetBSD support PAE (physical address extensions) which
> allow processes to take advantage of 32 bit hardware that can support
> greater than 4 GB of memory. FWIW, OpenBSD appears to not.
>
> If PAE is not part of the direction of DragonflyBSD, then it might be moot
> as to whether 32 bit is supported or not. You might be better of using
> FreeBSD, NetBSD, Linux, or even Windows.

PAE does not really allow a single process to grow beyond 4GB of
memory.  It is really
just a way to have the OS access more than 4GB of physical ram, and
map the extra
ram beyond 4GB into max 4GB address spaces for user processes to use.

One nice thing that PAE provides (at least today) is the NX bit, which
means that you
can do per-page no-execute, and don't need to use segment protections
to do this part.
So for that reason, I'd say that dropping i386 support for i386
without PAE support might
be a good idea.  However, it would not solve the "limited" VM space
problem, and it might
end up opening other issues, since a physaddr would be 64 bits, but a
vmaddr would remain
at 32 bits.  *shrug*  YMMWV.

-Toby.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]