Subject: Re: NetBSD on non-MMU systems???
To: Todd Vierling <tv@wasabisystems.com>
From: Gavan Fantom <gavan@coolfactor.org>
List: netbsd-advocacy
Date: 01/08/2002 17:32:47
On Tue, 8 Jan 2002, Todd Vierling 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).

Or a replacement for UVM/VM (say, SVM) which does not require an MMU. A
limited-functionality replacement, of course - shared memory and zero-copy
loaning just aren't going to happen without an MMU.

> 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.

You lose an efficient mmap(), certainly. I don't see why you need to lose
fork(). Not having an MMU doesn't prevent making a copy of memory, it just
means you can't use COW to do it. And, let's face it, fork() has been
around much longer than virtual memory.

As for vfork():

     Users should not depend on the memory sharing semantics of vfork(2) as
     other ways of speeding up the fork process may be developed in the fu-
     ture.

Proper shared text pages aren't going to happen. Anyone expecting this
from an MMU-less embedded system is living in a fantasy world. :)

> : > * 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.

Isn't that just a case of twiddling a few knobs?

> : > 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).

I didn't say it wouldn't. I said that arguable it *shouldn't*. That is,
if UVM, UBC and friends were cleanly pluggable entities etc etc, then
things would be different.

> 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".

The mail-index server appears to be down atm - I'll take another look
later.

-- 
Gillette - the best a man can forget