From: Vadim Lebedev (vlebedev@aplio.fr)
Date: Thu Jul 20 2000 - 11:37:58 EDT
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 2) add multihread support to ucLibc 3) add jffs support 4) implement .text segment sharing (if you launch sh twice only the .text segmnet will be shared between instances 5) implement loadable modules 6) add FLAT target to BFD, sw we get rid off xxx2flat utility 7) implement ELF loader 8) implement shared libraries 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/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:15 EDT