RE: [uClinux-dev] RE: [UCLINUX] Old kernel, old argument, new (maybe) point(s)

From: Bjorn Wesen (bjorn.wesen@axis.com)
Date: Thu Jul 20 2000 - 14:08:49 EDT


On Thu, 20 Jul 2000, Vadim Lebedev wrote:
> I think the fork stuff is too difficult to implement adequately, (one will
> have to tweak the
> compilers for EACH target arhitecture).

Well it wil be up to anyone for each architecture to make the choice -
it's not like it would require any arch-independant kernel rewrites.

> 1) implement a trivial malloc/free/realloc in libc which does not make mmap
> for each allocation, because mmap allocate stuff in PAGEs so you make
> malloc(12) and you get 1K allocated, very vasteful

But in uclinux, mmap uses kmalloc so you're not getting pages. You do
however get the next higher 2^x if you exceed 2^x-16 (depends on what
sizes bla bla) so if you malloc 4096 you're screwed :)

I used the real glibc actually for our designs first, with a real malloc
that got a large chunk from the kernel when the program started. It worked
like a charm of course since you didn't have to think about the uclibc
bugs, but it created too big footprints for our smallest products so we
had to use uc-libc on them. If you have 32+ megs in the product and 4+
megs of flash, the real glibc is ok, but not for like 8 megs ram.. 

> 3) add jffs support

I thought that already was in the tree. In any case you can just download
and unpack it from developer.axis.com, there is no real _need_ to merge it
into the uclinux source.

> 4) implement .text segment sharing (if you launch sh twice only the .text
> segmnet will be shared between instances

That is the same problem as with making fork() work. After all, two sh's
with the same .text and different .data, BSS and brk is the same that you
get after a fork :) 

> 8) implement shared libraries

We did that for our uclinux version. But due to the same problem as in
fork() and 4), you can only share on the flash and not in-core. Actually
we have a dependency graph among functions, objects and data in the
libraries, so those things that don't access global data can indeed be
shared but in uclibc for example that is quite a small part IIRC. 

The sharing in flash saves some precious bytes of flash though - better
saving some in flash than in DRAM if the choice has to be made.

-Bjorn


This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/


This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:15 EDT