Subject: Re: NetBSD on non-MMU systems???
To: Gavan Fantom <gavan@coolfactor.org>
From: Todd Vierling <tv@wasabisystems.com>
List: netbsd-advocacy
Date: 01/08/2002 10:38:21
On Tue, 8 Jan 2002, Gavan Fantom wrote:

: > Yes.  Among the tasks that need to be done to make this happen:
: >
: > * rip out UVM and UBC entirely via #if conditionals, and replace with buffer
: >   cache only
:
: Given that UVM and UBC are relatively new things to NetBSD, one has to ask
: why UVM and UBC aren't already separated out.

The entire concept of virtual memory has to be separated out, which is
something not nearly so new (it dates back to 32V, 22 years ago, and has
existed in the entire lineage leading to NetBSD).

You then lose things such as mmap() and fork()[!!] and have to do some more
"interesting" things to implement vfork() and proper shared text pages.

: > * rework toolchain to produce PIC code for all userland, including linked
: >   binaries
:
: For some architectures (including the ARM), it is quite difficult to write
: non-PIC code. Of course, the toolchain still manages it. :)

This is mainly in the output of final binaries and their handling by the
kernel and dynamic loader.  In short, all binaries end up needing handling
as if they were shared objects.

: > I'd estimate that the above alone would take at least several months.
:
: Yes it probably would. But arguably it shouldn't.

No, this would likely take several months of *dedicated* work.  Hence why
it's only been seriously offered under commercial guise (because there isn't
the volunteer manpower to do it).

This issue has been analyzed and hashed over a couple times on mailing
lists; if the mail-index.netbsd.org search is working again, you could
search for "without mmu".

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/