From: D. Jeff Dionne (jeff@lineo.ca)
Date: Thu Jul 20 2000 - 15:12:01 EDT
Vadim Lebedev <vlebedev@aplio.fr> said: > > I think the fork stuff is too difficult to implement adequately, (one will > have to tweak the > compilers for EACH target arhitecture). > > Here are my list of things to do > > 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 A very useful thing to implement. I believe there are a few implemetations of that floating around. I will take patches for uC-libc for that if anyone has a good one. > > 2) add multihread support to ucLibc That would be nice, but not strictly necessary until linuxthreads (pthreads) is ported. > > 3) add jffs support jffs support is in the standard uClinux kernel. Thanks again to Axis for the contribution. > > 4) implement .text segment sharing (if you launch sh twice only the .text > segmnet will be shared between instances uClinux has always done this... Unless you are loading the .text segment into RAM, which there is no need to do if you have a PIC compiler, .text is XIP from FLASH. > > 5) implement loadable modules Don't remember what the sticking point here was... It was non trivial... Oh yes, modutils was difficult to port, the kernel side was easy. > > 6) add FLAT target to BFD, sw we get rid off xxx2flat utility bFLT is essentially the minimum you need, just a little more than a flat binary image (hence, bFLT). You can likely get this together fairly easily, but I would suggest that it's not a big win since you'll still need COFF or ELF anyway. > > 7) implement ELF loader binfmt_flat.c is derived from binflt_aout.c. Running a diff results in only ~750 lines. The ELF loader should be fairly easy to beat into submission. > > 8) implement shared libraries After ELF? Ok. J > > 9) add NOMMU support to latest kernel > > > This list is sorted by percieved difficulty > > > Vadim > > > > > > > > -----Original Message----- > From: owner-uclinux-dev@uClinux.org > [mailto:owner-uclinux-dev@uClinux.org]On Behalf Of Joe deBlaquiere > Sent: jeudi 20 juillet 2000 16:35 > To: 'Tom Walsh'; 'David Smead' > Cc: uclinux@c3po.kc-inc.net; Uclinux-Dev (E-mail) > Subject: [uClinux-dev] RE: [UCLINUX] Old kernel, old argument, new > (maybe) point(s) > > > In general, I have to admit I agree with you... trying to make a > microcontroller into a minicomputer is not the idea. Yet there are some > fairly powerful CPUs already in the uClinux family. I've been working with > an ARM7TDMI variant with reasonable uumph, and I know there are faster ones, > including some really screaming Coldfire chips. > > Also, I have to agree that I would never write a program from scratch that > used fork() where it couldn't use vfork(). For anything else, pthreads is > the way to go. It works very very nicely, sharing code and data with a new > stack. Highly efficient. What more could you want? > > The problem arises when you want to use a program like the DHCP client pump. > A little re-writing was necesary to make it work. One could debate whether > the original design was 'optimal', but I really didn't care. I needed a > capable DHCP client, and it worked. But it's going to be a pain in the butt > if a customer decides they need a feature that is only supported on a newer > version of pump and I have to go back and port that one too. And the use of > fork() in pump is FAIRLY SIMPLE. There are plenty of applications that > people are going to want that are MUCH MESSIER (or is that more messy? ;o). > > My real dream is to kill the uClinux project... But in a good way. I would > like to eventually see the 'nommu' targets included in the main > distribution. I know of several new architectures that lack an mmu and could > make nice uClinux targets. > > At this point, it looks to me like fixing fork() would be no small task and > would break some other things, such as mmap(). Is this a choice we want to > give people at compile time? Is there another solution out there? > > BTW : did anybody notice the other three points of my orignial email??? ;o) > > --Joe > > > -----Original Message----- > > From: owner-uclinux@c3po.kc-inc.net > > [mailto:owner-uclinux@c3po.kc-inc.net]On Behalf Of Tom Walsh > > Sent: Wednesday, July 19, 2000 5:33 PM > > To: David Smead > > Cc: uclinux@c3po.kc-inc.net > > Subject: Re: [UCLINUX] Old kernel, old argument, new (maybe) point(s) > > > > > > David Smead wrote: > > > > > > You can emulate anything in software, except the speed of hardware. > > > > > > Adding the overhead of base register emulation is going to cost you > > > processor cycles - a bad deal in realtime - and its going > > to cost you > > > power - bad if you're running from a battery. This latter > > claim assumes > > > that you have a idle loop that includes deep sleep, and you > > spend less > > > time there because every wakeup call takes more processor cycles to > > > complete. > > > > <Yawn>! This thread is going nowhere fast, this sounds like the 'silk > > purse from a sow's ear' syndrome to me... IMHO, if you need > > it light + > > simple + fast + cheap, use a cheap 32bit controller sans MMU > > + uClinux, > > if you need to have the full complement of a real linux version > > capabilities, then choose a processor with an MMU and go mainstream > > linux. For me, the DragonBall + uClinux is the solution in some > > situations, while the ARM + linux is the solution for others. I don't > > see a problem here? As David points out, when doing realtime > > programming, cycles are King, the o/s is secondary! > > > > TomW > > > > > > > > -- > > Tom Walsh - WN3L - Embedded Systems Consultant > > 'www.openhardware.net', 'www.cyberiansoftware.com' > > "Windows? No thanks, I have work to do..." > > > > This message resent by the uclinux-dev@uclinux.org list server > http://www.uClinux.org/ > > This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/ > -- D. Jeff Dionne Jeff@lineo.ca -VP Research and Development, Office of the CTO Lineo - Put Linux Anywhere 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