So what can uClinux do ?
Isn't the MMU facility based on suitable hardware, too ?
==TIA.
> I'm interested in linux on minimum electric consumption
> hardware. Surely, linux being a pre-emptive multi-tasking OS
> *MUST* have substantial memory-management ?
It depends.
> So what can uClinux do ?
It can do much of what "normal" linux can do.
> Isn't the MMU facility based on suitable hardware, too ?
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!!
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
spamt...@verizon.net
(Yes, that is one of my email addresses.)
> 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 ?
>
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..." |
--
.~. 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