I'm interested in linux on minimum electric consumption hardware.
Surely, linux being a pre-emptive multi-tasking OS *MUST* have
substantial memory-management ?

So what can uClinux do ?

Isn't the MMU facility based on suitable hardware, too ?

==TIA.

On 2008-07-19, problems@gmail <problems@gmail> wrote:

It depends.

It can do much of what "normal" linux can do.

No clue what you're asking.

Try reading a little:

  http://www.uclinux.org/
  http://en.wikipedia.org/wiki/%CE%9CClinux

--
Grant Edwards                   grante             Yow!  My forehead feels
                                  at               like a PACKAGE of moist
                               visi.com            CRANBERRIES in a remote
                                                   FRENCH OUTPOST!!

On 2008-07-19, Grant Edwards <gra...@visi.com> wrote:

The Amiga 500 and 1000 computers I used to have at home ran
an operating system that was fully "pre-emptive
multi-tasking" without any memory management.  There was
_NO_ protection from one task corrupting the memory of
another process.

--
Robert Riches
spamtra...@verizon.net
(Yes, that is one of my email addresses.)

It can run on hardware that doesn't have an MMU.  That's less and less of
an issue, but even a decade ago a lot of hardware didn't have one which
meant you couldn't use that Mac LC II for Linux.

I ran a mult-user/multitasking operating system back in 1984, Microware's
OS-9.  Not a bit of MMU, though OS-9 level 1 did require an MMU.
Microware had previously done a tiny multitasking monitor/OS for the 8bit
6800.

I have a book about the 68000, and it has a small mutlitasking monitor/OS
in it.

Multitasking doesn't require memory management, it just works
better/faster.

    Michael

Better/slower.

All that preemptive multitasksing requires is that each process has its
own code space, and data space and most importaantly stack space.

You ca write your alloc() stuff to deal with large allocations on the
heap etc, but the allocatin of static variables and dynamic variables is
done on a area of ram that you need to reserve on a per process basis.
So any fork() has to know how much memory to grab for it..if thats done
by calls to your alloc, then its not too bad. Hey you have just made
your own MMU! In software.

However if memory gets fragmented, you are in trouble, since the stack
and heap MUST be contiguous..a hardware MMU can fake that even if in
reality they are not.

And safer...

--
|   spi...@freenet.co,uk   | "Are you pondering what I'm pondering Pinky?"   |
|   Andrew Halliwell BSc   |                                                 |
|            in            | "I think so brain, but this time, you control   |
|     Computer Science     |  the Encounter suit, and I'll do the voice..."  |

True. You get a segfault instead of crashing the entire system ;-)

IIRC, the PDP-11/20 that UNIX was developed on had no MMU. I had a PDP-11/45
with 48K Bytes of RAM and because of the users I had and the applications
they needed to run, we got Ken (and maybe Dennis) to revise the kernel to
use the MMU. This was long ago when the UNIX kernel was written in assembler
and the maximum file size was 2^16 bytes.

--
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key: 9A2FC99A         Registered Machine   241939.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 08:35:01 up 23 days, 17:55, 4 users, load average: 4.37, 4.25, 4.19