[MiNT] Patch for MMAP?

[evan@coolrunningconcepts.com]

Quoting Mark Duckworth <mduckworth@atari-source.com>:

> I thought mainly in terms of jacking necessary headers and code to
> continue the porting storm.  As far as your last question is concerned -

Just did some checking - it appears that while further development of 
uClinux is
still seperate, as of linux kernel 2.6, uclinux is part of the mainstream
kernel.

> I do not know, but I'd assume it's possible but slow without an MMU? I

Not exactly.  The MMU allows you do things that aren't normally 
possible without
an MMU.  For example, MMU system don't need relocation information since all
processes will generally load into the same virtual address.   Your stack and
heap can dynamically resize, and files larger than physical memory can be
loaded  via mmap() since only the page of RAM that you are actually accessing
at this instant needs to be mapped to physical RAM (and the rest of the file
you don't even need swap for since the file is memory backed).  There 
were some
cases where an MMU could do things like piping and such better than a memory
copy, but most modern CPUs can do a burst mode memory transfer so fast, that
its not worth modifying the page table entries unless you are moving a
significant amount of data ... normally larger than the contents of a pipe
buffer.

Now, in the case of fork(), where you pretty much HAVE to have the 
child in the
same address space (because of pointers), MiNT swaps the parent and child in
and out of RAM (massive memory copying), which won't be efficient at all.  I'm
curious if the library call tfork() does this - I would think it would 
have to.
 I'd like to see a better thread system under MiNT, but without an MMU, we're
stuck.

What I was thinking, was a small hack to mintlib that would perform a couple
simple operations to emulate a real mmap().  This is a call that does
everything from load processes, to allocating memory, to giving access to
graphics frame buffers, to allocating (or mapping hardware) network 
buffers, to
mapping files and providing shared memory.  Lots of stuff is built on 
this, and
we can't do a real implementation, so a do-able hack in mintlib might be the
best we can do.

Details are based around mapping of files, and we can add functionality later.

Version 1 - no sharing.  This mmap() would have to use Fopen() to open 
the file.
 If an address is given, we could possibly use it, but it may be best to just
pretend a given start address is 0.  If the start address is 0, call Mxalloc()
to allocate a chunk of memory equal to the size of the file with the proper
protection as specified, load the entire file into the block, close the file,
and return the pointer.  munmap just frees the pointer.

Version 2 - sharing possible.  We could further expand on version 1 by first
checking to see if a file in /SHM exists that is the same.  We can then simply
use Fcntl to grab a pointer to the shared memory block.  If no such file
exists, call Fcreate() to create a file in /SHM and attach the memory block to
it with Fcntl before returning it to the application.

This should give most of the semantics of mmap() except that files larger than
memory can be addressed.  Smaller shared files and memory blocks should work
fine.  Since the actual use of mmap() in busybox, at least at the point that I
encountered this issue, was for loading an RPM.  Considering how big an 
RPM can
be, it may not be efficient to load the whole file into RAM, and that 
is pretty
much what has to happen if you don't have an MMU - so this is when I gave up
and shelved busybox.   You'd want a new version of RPM that doesn't use 
mmap().

I don't currently trust my system since when I tried to compile my own 
MiNT and
XaAES for aranym, it just crashed, and I have no idea what is at fault.

Also, you want busybox to run pcrelative if at all possible and use the
shared-text bit of MiNT.   MiNT still does the mbaserel text shared stuff
doesn't it?

> don't know much about the function of mmap versus what the MMU allows
> for.  I'm pretty sure ARM/XScale has an MMU but no FPU (which is
> annoying to a certain extent :-/ ).

Depends on which ARM.  I think most of the Xscale stuff has an MMU, and 
you are
right, no FPU.   In practice, the lack of an MMU makes the whole OS a pain,
while the lack of a FPU isn't all that bad since many programs are being
written to use fast integer math instead of floating point math - mainly
because of the popularity of ARM.