On Sun, 29 Aug 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Bjorn Wesen writes:
> : you can forget memory protection, but multitasking has nothing to do with
> : MM so that is no problem. the problem is how to implement the unix
> : semantics of fork(), and other MM tricks like demand loading and sharing
> : of text/data that support the multitasking model.
>
> mmap becomes nearly impossible as well, which eliminates shared
> libraries (or at least the sharing that libraries do when shared).
This is two separate issues. The mmap() syscall is still available for
anything that has a fixed address within an addressible memory area.
Depending on how the system is arranged, this can include the video frame
buffer, and even "files" store in a ROM file-system. uClinux has a bit of
magic for this that works fairly well, given that it is an ad hoc hack.
You'd be surprised how much of mmap() can be implemented without an MMU,
though. Shared anonymous maps just work out to be a sort of malloc().
Indeed, the user-level malloc() and free() routines are implemented in
terms of mmap() and munmap(), which is, in turn, implemented in terms of
the kernel's kmalloc() system.
Memory mapped files, in the dynamic-memory-backed-by-files sense, are
indeed nearly impossible without an MMU, or at least completely different
assumptions about memory management. (It is conceivable, for example, that
mmap()'ing a file could suck the file up into a linear set of buffers in
the buffer cache, locking them so they won't get flushed. Any other
callers wanting to map the same file would get the same buffers. Some sort
of interlock would be needed to make disk access flush the appropriate
buffers (this may already be in place), and some way of shuttling buffers
around would be necessary to extend such a mapping in-place. Multiple
mappings at different addresses would not be possible.)
> : linux itself works fine without MM (since the kernel is mostly linearly
> : mapped anyway) but fork() can only make a new thread, not a new MM, so the
> : child will share data with the parent. you need to take this into
> : consideration when writing applications for uclinux (and other MMU-less
> : linuxes) as well as that there are limitations in the MM API (mmap et al)
>
> Yes. Exec also becomes interesting...
Actually, no, exec() is trivial, though you do need to use vfork() to
create the a new sub-process, instead of fork().
Basically, uClinux shares a good chunk of the limitations of traditional
(let us say PDP-11) UNIX, although unfortunately it does not have all of
the benefits. Specifically, 68xxx processors lack segments, which provide
a primitive but functional MM facility. Without segments (or some other
mechanism of atomically applying an offset register to all stack, PC, and
.data references), swapping is non-trivial. (Most other fancy
facilities, such as defragmenting memory, can be built on top of
swapping.) Oddly enough, an 8086 Linux port should do much better in this
regard, though I've not kept up with ELKS.
> I did try to get NetBSD running on a Vr4650 once, but with only base
> and bounds I gave up as producing a system that was too un-unix-like
> to be useful.
>
> Warner
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
