Subject: Re: NetBsd on MMU-less CPU's
To: Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>
From: Todd Vierling <tv@wasabisystems.com>
List: netbsd-ports
Date: 06/06/2001 22:41:42
On Wed, 6 Jun 2001, Hubert Feyrer wrote:
: It sure would be nice to have NetBSD support MMU-less systems, but maybe
: you can go into some details on how uClinux works around an MMU?
I don't know about uClinux, but the principles are pretty simple (if a bit
tedious to accomplish from scratch):
* PIC everywhere, except perhaps the kernel. This could require a new
MACHINE_ARCH definition on some platforms, or simply a little more ELF
glue for program startup on others. *Everything*, except perhaps .data
and .rodata relocs, needs to go through the PLT and GOT. RSS .text
relocations are fatal, unless the .text is loaded separately per-process
(effectively making it act like .data); a memory waste.
* Supplant the VM system with a buffer cache and malloc() manager only.
This could be done on NetBSD with proper abstraction/encapsulation.
* Supplant malloc() with something like a pool allocator, which frees
its memory list at exit().
* Replace mmap(), fork(), and other VM-dependent calls with ENOSYS ... or
don't even provide the libc symbols at all (so that they don't appear to
exist to things like autoconf).
* Provide only the "proper" version of vfork() (we call it __vfork14()).
* Provide a special "in-place" version of daemon() (which creates an
orphaned proc structure, but doesn't change memory).
and optionally:
* Provide the spawn*() family. These are well recognized and their presence
encourages friendly fork/exec use by encapsulating it in one call.
* Encourage use of daemon() for backgrounding processes (rather than
fork/exit).
* Make sure you run code that is friendly to memory. Code that can't pass
Purify is fatal.
...Feel free to transcribe this braindump somewhere if you'd like. 8-)
--
-- Todd Vierling <tv@wasabisystems.com> * Wasabi NetBSD: Run with it.
-- NetBSD 1.5 now available on CD-ROM -- http://www.wasabisystems.com/