
Nommu Linux - signa11
http://nommu.org/
======
Retr0spectrum
I'm a little bit confused as to what this site actually is.

Is nommu a fork of the linux kernel like uclinux? If so, where is the source?
Or is it just a guide for programming on MMU-less systems (e.g. uclinux).

I'm planning a MC68020 SBC project. My current goal is to get uclinux running,
but I'd be interested to see what else I can run on it.

~~~
pantalaimon
nommu has been part of the mainline kernel for many years now, no fork needed.

~~~
Retr0spectrum
Ah, so it is. I feel like they should have stated that in the introductory
paragraph.

------
jiri
I dont see "why"? Any ideas?

~~~
TickleSteve
Practically... no one would really use this.

Anyone wanting a scheduler on a microcontroller based system would not want
the baggage of a linux-level general purpose OS. You use a simple scheduler
such as FreeRTOS/RTX/etc.

These days the only systems without full MMUs are microcontroller-based ones
for which this is not appropriate. No embedded system is going to be
dynamically-loading applications like this, its all bare-metal, all built into
the one image.

No-MMU linux did have a use back when say the 68000 based lines were still in
wide use, but these days all I can think of is for user-space linux where
everything is simulated in a single process under a full general-purpose OS.

~~~
kristoffer
There are still CPUs without MMU where one would like to run Linux (e.g.
J-core or other FPGA soft cores).

One good reason for using Linux instead of any of the RTOS is better
networking support. I've used VxWorks, RTEMS, Nucleus, FreeRTOS, eCos, etc and
their networking stacks are all pretty slow and crappy.

~~~
joezydeco
There's also way better input and output support.

I recently did a project with ucLinux on an LPC1788 (Cortex-M3). Getting the
USB host stack is always a pain in the ass, but it was dirt simple on the
Linux port.

Same for LCD framebuffer, GPIO, touchscreen (unique animals every time), I2C,
SPI, etc etc etc. And I can pull anything I want off the kernel tree and not
have to spend a week getting it working on another OS.

------
pathompong
I had a IP camera running uclinux [1] on ARM7 years ago. The camera was
connected to the CPU with USB interface internally. I guess the benefit with
using Linux was free ip, USB, and uvc stack.

1\. [http://www.uclinux.org](http://www.uclinux.org)

------
Rangi42
TempleOS already does this. ("This" being "no virtual addresses".)

------
aMayn
So basically like programming for AmigaOS 3.x?

~~~
digi_owl
Kinda. Best i can find is that AmigaOS didn't have memory protection because
the 68k initially didn't have it, but later variants got it (68030 onwards?).

I think there was similar issues with (classic) Mac OS and Windows 9x.

~~~
buserror
Classic MacOS dealt with the memory fragmentation in a pretty neat way tho.
All code was relocatable to start with, and pretty much _every_ memory block
you'd allocate was also relocatable by using one further level of indirection
called a Handle. A Handle was basically a pointer to a pointer. A Handle
defaulted to 'unlocked' so the actual memory block could move at any time;
unless you Locked it, and Unlocked it afterward.

This allowed the OS to compact the memory heap, move all the relocatable
blocks in one corner and allow further contiguous blocks to be allocated.

Of course, this is a primitive concept these days, but it allowed amazing
pieces of software to exist on very, very small memory systems.

~~~
jakobegger
I fondly remember playing with Photoshop 2.5 on my Color Classic with its
16MHz CPU with 10MB RAM... It was amazing what you could do on such a
"primitive" machine.

~~~
buserror
Photoshop was a little bit of a masterpiece back then (it arguably still is,
deep down) -- it had it's own 'swap' system for large pixmaps that allowed you
to work on images that were massively bigger than the onboard memory; and it
wasn't even that slow (unless you were applying filters on the whole image).

------
rasz_pl
Why: Even 10 years ago some routers/set-top boxes ran on mmuless
SoCs(Coldfire, lexra LX4180), and stayed on uclinux even after switching to
new processors with mmu.

[http://paparisa.unpatti.ac.id/linux_journal_archive_1994_200...](http://paparisa.unpatti.ac.id/linux_journal_archive_1994_2007/LJ/160/9691.html)

------
vadiml
What is difference between nommu linux and uclinux?

~~~
poizan42
That uClinux got merged into the mainline kernel and is basically the nommu
support today, at least as far as I understand it.

------
fsiefken
It reminds me of the ELKS project to run Linux on i8086-i286. What would be
the advantages or disadvantages of this compared to uClinux? For example
perhaps it's raison d'etre is that you can run it on Cortex-M0 for ultra low
power

~~~
TickleSteve
No one using a microcontroller-based system would be wanting dynamic loading,
etc.

This is purely a curiosity-satisfying project it seems.

~~~
pantalaimon
> This is purely a curiosity-satisfying project it seems.

[http://www.emcraft.com/](http://www.emcraft.com/) suggests otherwise

------
thedjinn
So who actually checks return values of malloc, and why? (or why not?)

~~~
Retr0spectrum
IMHO checking the return value is only useful if you can actually do something
about it.

For example, you might want to gracefully write a database to disk before
terminating the program.

It's definitely bad practice, but if you run out of memory during the
initialisation of a program, quitting with a segfault is a fairly reasonable
error. Of course, catching the error and printing something meaningful would
be much better, but if you're in a rush to get something to work for a
personal project it's not much of an issue.

~~~
thedjinn
The article states that malloc only fails when you run out of virtual address
space, which is basically never going to happen if you're on a 64 bit
architecture. So you can go for good practice and check all your mallocs for
failure, but if the failure never happens why bother?

~~~
detaro
As far as I know, only Linux behaves like this, and even there it is
configurable. (keyword is "memory overcommit", there are sysctl settings for
it)

------
DeepYogurt
Neat, but why?

~~~
bluejekyll
Answered above. Some micro-controllers or fpga's ship without MMU's, this is
needed if you want to run Linux.

------
sshb
There is no obvious practical application for such system. So "why?" is
irrelevant here.

Never the less taking such common abstraction as MMU and disabling it is
awesome illustration of OS architecture.

~~~
pjc50
It's for running on systems that don't have an MMU, not disabling it.

