On Thu, 26 Aug 1999, Bjorn Wesen wrote:
> 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.
Oh, yes, another trick uClinux uses (and could go a bit further with) is
sharing everything that can be shared, never mind the abscence of an MMU.
If .text is supposed to be read-only, we should only have to load it into
RAM once. (Though, currently, we don't. If it's in ROM, we don't load it
into RAM at all, of course.)
> you also need to either relocate all loaded text or compile it as position
> independent code (since you can't put all segments at their original
> VMA's). we relocate, i think uclinux uses PIC.
PIC on 68000 devices, relocation on ColdFire, though that code isn't
completely merged yet.
> so to recap, the kernel itself is _comparatively_ easy to remove MM from,
> compared to the problems you'll get with shared libraries, ill-behaved
> programs, buggy programs, and programs that want to use fork() and MM.
Basically, yes. One interesting side-effect of using something resembling
a normal desktop Linux environment is that most code can be tested on the
desktop, complete with Electric Fence (or equivalent) linked in, and then
run in uClinux once some basic sanity checks have been run.
> oh yeah, one other big issue is memory fragmentation. you can't map
> together pages spread in memory, you need consecutive pages for loading
> executables etc. and it's no fun trying to allocate, say, 200 KB after
> you've run a linux box for a while using page cache and buffer caches
> spread all over memory.
Correct. Well, some of this is moot (any cache that can be flushed will
be, and I suspect that some of it which cannot be actually flushed could
actually be defragmented.) But the problem is compounded by the fact that
the current kernel allocator (power of 2 buddy system) is extremely bad
for this sort of thing -- or so everybody tells me. I've not yet actually
found a different implementation that I could try, nor an exact statement
of how poor the buddy system is in practice compared to other techniques.
There's a whole suite of connected problems here. If he had swapping, we
could swap program sections out to help defragment the system. Or, if we
had some sort of allocation system based on handles instead of pointers
then we could swap or move any unlocked handles. As I mentioned, I suspect
some amount of movement of locked buffer-cache entries is already
feasible, which would specifically benefit us because RAM disks are made
out of locked buffer cache pages.
To some degree, the general problem can be limited by making one of the
usual assumptions for embedded hardware: the device is special purpose,
and is not intended to run an arbitrary set of programs.
--
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>.
