Hi! > -----Original Message----- > From: Erich Titl [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 4:25 PM > To: Natanael Copa > Cc: leaf-devel@lists.sourceforge.net > Subject: Re: [leaf-devel] 2.6.x kernel support? > > > Natanael Copa wrote: > > Erich Titl wrote: > > > .. > > > > I dont have time for reading about memory management in Linux right > > now, but AFAIK the executables and libraries are mmap'ed. > > This would mean, that an executable would onle be mapped to > memory, but > copied as soon as the memory page it resides on is written to > by anyone. > This could produce some interrupts. > ... > I don't know if I should/can consider a RAMdisk simply RAM. > It needs to > behave like a disk in the sense of logical I/O. > > ... > > > > It would really not make any sense to copy a mmap'ed > executable from > > RAM to another place in RAM, > > That would be true if RAMdisk does just mapping. > > but as I said, I'm not 100% sure about that and > > currently I dont have time to investigate it (so, strictly > I should > > have kept my muth shut, but now its to late anyway...:) > > Same for me, still it is an interesting object. Maybe someone with > deeper insight into RAMdisks on Linux could tell. >
Is this whole conversation about loading to ram, using initramfs or any other kind relevant to the current branches of LEAF? The way I see it, the team i'm part of has already analysed the implications of switching over to 2.6 kernels, including the need for a new initial filesystem. For several reasons we have already gave to the community, we have decided that for now, 2.6 and all that goes with it, is not really a great improvement. Which means that we (Bering-uClibc Team), are going to continue supporting a bootable floppy version, using a basic set of a complete, stable production grade router/firewall. For me personally that is a goal to maintain as long as possible, have a floppy based firewall. Altough I don't use floppy-based setup any longer, I still feel that if we make all efforts to keep supporting it, we will maintain focus. Having a larger boot media will lead to all sorts of excesses... Still, one idea from Erich was retained in my mind, and has also lurked in my ideas from time to time, which is the firmware thing... Discussing this will open a whole new can of worms, what should be considered basic and essential? Who will have the power to decide which stays in the firmware or not? We don't want to loose the modular design we have now. Not being able to backup the initramfs for example is not a very nice thing. I think we may be loosing too much time discussing stuff with little or no result... The central DB design comes to my mind for example... So, unless someone has a good small footprint design using the latest available techologies, providing the same capabilities we have now, lets leave the matter for now. p.s. please treat my opinions as my own and not as if I was talking on behalf of the Bering-uClibc Team! Luis Correia Bering uClibc Team Member PGP Fingerprint: BC44 D7DA 5A17 F92A CA21 9ABE DFF0 3540 2322 21F6 Key Server: http://pgp.mit.edu ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
