Menu
▾
▴
leaf-devel
|
From: Peter M. <pmu...@si...> - 2005-07-12 21:00:47
|
> Is anyone working on the 2.6 kernel yet? Just curious here, what features does a 2.6 kernel have that leaf can = use? I've heard a lot about the scalability but I haven't seen this in the = real world yet. Regards, P |
|
From: Eric S. <e.s...@in...> - 2005-07-12 21:10:18
|
Hello Mike, Currently we are not working on it, but we do look at kernel development ofcourse. Kernel 2.6 is much bigger than 2.4, it needs a lot of changes in the base packages (to make full use of the functions) and it has no real benefit for leaf now. Eric Spakman >Is anyone working on the 2.6 kernel yet? > >-- >Mike Noyes <mhnoyes at users.sourceforge.net> >http://sourceforge.net/users/mhnoyes/ >SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs > > > >------------------------------------------------------- >This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening >July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual >core and dual graphics technology at this free one hour event hosted by HP, >AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > >_______________________________________________ >leaf-devel mailing list >lea...@li... >https://lists.sourceforge.net/lists/listinfo/leaf-devel > >> [Message truncated. Tap Edit->Mark for Download to get remaining portion.] |
|
From: Mike N. <mh...@us...> - 2005-07-13 01:23:06
|
On Tue, 2005-07-12 at 14:09, Eric Spakman wrote:
> Currently we are not working on it, but we do look at kernel
> development ofcourse. Kernel 2.6 is much bigger than 2.4, it needs a
> lot of changes in the base packages (to make full use of the
> functions) and it has no real benefit for leaf now.
Eric,
Thanks for the information. :-)
It looks like the 2.6 kernel is only advantageous for RT embedded
applications.
Google string: linux 2.6 embedded debian|gentoo
vs
Google string: linux 2.6 embedded debian|gentoo router
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Mike N. <mh...@us...> - 2005-08-18 21:48:40
|
On Tue, 2005-07-12 at 14:09, Eric Spakman wrote:
> Currently we are not working on it, but we do look at kernel
> development ofcourse. Kernel 2.6 is much bigger than 2.4, it needs a
> lot of changes in the base packages (to make full use of the
> functions) and it has no real benefit for leaf now.
Eric,
Initramfs and ramfs may provide benefits to leaf branches.
Re: Initrd and Initramfs
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.0/0739.html
Initramfs arrives
http://lwn.net/Articles/14776/
Ubuntu is using initramfs rather than initrd for Breezy Badger.
Ubuntu Breezy Badger "Colony 3" now available
http://lwn.net/Articles/148200/
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Mike N. <mh...@us...> - 2005-08-19 15:45:18
|
On Thu, 2005-08-18 at 23:45, E.S...@in... wrote: > It's not very trivial to move to initramfs. Currently we use busybox in > initrd which is compiled against uClibc, initramfs is using a method off > "pre-init" programs which must be compiled against klibc. This means > having the same type of programs compiled against klibc (which can't be > busybox, because that won't be compiled against klibc) in initramfs and > userspace programs (busybox) compiled against uClibc (or glibc in the case > of plain Bering). Eric, I'm seeing people use initramfs with busybox. From what I understand either uClibc or klibc can be used with initramfs. Google string: initramfs busybox http://sourceforge.net/mailarchive/forum.php?thread_id=7934561&forum_id=5348 Google string: initramfs uclibc klibc http://www.redhat.com/archives/dm-devel/2004-September/msg00008.html > Implementing initramfs would mean a lot of redundancy and added size. > Besides not all programs we need in pre-init have a klibc version (like > makedevs f.e.). I'm not understanding how this change would introduce redundancy. Of course, size is always a concern. > We already use ramfs b.t.w. But what is currently the real benefit of > initramfs to LEAF? The lwn article sums up the benefits, but I'm still looking for a better overview of the features/benefits. Initramfs arrives http://lwn.net/Articles/14776/ > The combination initramfs and kernel 2.6 makes the distro 50% bigger. Have you tried it? I'm seeing boot images from other projects that are approximately 1.5M. Another interesting klibc and initramfs link: http://fxr.watson.org/fxr/source/Documentation/early-userspace/?v=linux-2.6.9 -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Mike N. <mh...@us...> - 2005-08-19 17:32:18
|
On Fri, 2005-08-19 at 08:48, Mike Noyes wrote: > On Thu, 2005-08-18 at 23:45, E.S...@in... wrote: > > We already use ramfs b.t.w. But what is currently the real benefit of > > initramfs to LEAF? > > The lwn article sums up the benefits, but I'm still looking for a > better overview of the features/benefits. > > Initramfs arrives > http://lwn.net/Articles/14776/ An initramfs howto http://www.vas.nu/pipermail/klibc/2005-August/001111.html -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Charles S. <ch...@st...> - 2005-08-19 17:33:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Noyes wrote: | On Thu, 2005-08-18 at 23:45, E.S...@in... wrote: |> We already use ramfs b.t.w. But what is currently the real benefit of |> initramfs to LEAF? | | The lwn article sums up the benefits, but I'm still looking for a | better overview of the features/benefits. To me, it looks like the new initramfs would make it possible to do something like the old LRP patch (which allowed the kernel to use a tar.gz file as an initial ramdisk image) without requiring a kernel patch. It also looks like a handy way to solve various boot-strap problems (like getting a kernel with built-in RAID to look for RAID images *AFTER* some external module is loaded). A lot of this stuff is currently (at least circa 2.2/2.4, which I'm more familiar with) kind of 'hacked' into the kernel, and if your boot sequence is particularly odd, you might have to patch the kernel (or load an excessively large initial ramdisk). This feature might be useful in making a very small initial ramdisk image for leaf that 'bootstrapped' the full LEAF system, and would not require a C library of it's own (instead using klibc and essentailly making direct kernel calls). You'll never be able to run bind or sendmail this way, but being able to run a simple shell (or other script processor like forth, lua, etc.) and do things like extract tar files to build a root filesystem image would be all we'd need. This would eliminate the 'special' file that has existed in LRP/LEAF since the beginning (ie: root.lrp or initrd.lrp), replacing it with a (hopefully) standard chunk of init code that was simply linked with the kernel. - -- Charles Steinkuehler ch...@st... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBhfRLywbqEHdNFwRAmVaAKC4ctI4urM+d2fudhAHPB6kPow07gCfeN8c 9COK9Mms7v+4FAAzqVYnw3k= =fP/3 -----END PGP SIGNATURE----- |
|
From: <E.S...@in...> - 2005-08-19 19:26:53
|
Hello Mike, Charles, Still only have webmail, so I hope it will show up on the list > This feature might be useful in making a very small initial ramdisk image > for leaf that 'bootstrapped' the full LEAF system, and would not require > a C library of it's own (instead using klibc and essentailly making direct > kernel calls). You'll never be able to run bind or sendmail this way, > but being able to run a simple shell (or other script processor like > forth, lua, etc.) and do things like extract tar files to build a root > filesystem image would be all we'd need. > This is what I mean with redundant, you would need a shell (and other programs) in the initramfs (pre-init) and in userspace which isn't the same one. So you need the space for a klibc compiled shell in the initramfs and an other (uClibc/glibc) compiled shell in root.lrp (or so), while currently we use one shell which is both used for pre-init (linuxrc) and userspace. It isn't possible to use the klibc initramfs programs in userspace (AFAIK), which would be pointless anyway because the klibc versions are/should be very limited in functionality/size. For Mike: There are ofcourse images of ~1.5 Mb which contain an initramfs and 2.6 kernel, but they don't contain all the programs we have in such an image ;) But I agree, the initramfs approach would make a technical cleaner implementation. But it also means (because of redundancy and a bigger kernel (2.6)) a bigger base image. I also don't see a lot of real advantages for our case yet. Eric Spakman |
|
From: Charles S. <ch...@st...> - 2005-08-19 22:02:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 E.S...@in... wrote: | Hello Mike, Charles, | | Still only have webmail, so I hope it will show up on the list | |> This feature might be useful in making a very small initial ramdisk image |> for leaf that 'bootstrapped' the full LEAF system, and would not require |> a C library of it's own (instead using klibc and essentailly making direct |> kernel calls). You'll never be able to run bind or sendmail this way, |> but being able to run a simple shell (or other script processor like |> forth, lua, etc.) and do things like extract tar files to build a root |> filesystem image would be all we'd need. |> | This is what I mean with redundant, you would need a shell (and other | programs) in the initramfs (pre-init) and in userspace which isn't the | same one. So you need the space for a klibc compiled shell in the | initramfs and an other (uClibc/glibc) compiled shell in root.lrp (or so), | while currently we use one shell which is both used for pre-init (linuxrc) | and userspace. | It isn't possible to use the klibc initramfs programs in userspace | (AFAIK), which would be pointless anyway because the klibc versions | are/should be very limited in functionality/size. | | For Mike: There are ofcourse images of ~1.5 Mb which contain an initramfs | and 2.6 kernel, but they don't contain all the programs we have in such an | image ;) | | But I agree, the initramfs approach would make a technical cleaner | implementation. But it also means (because of redundancy and a bigger | kernel (2.6)) a bigger base image. I also don't see a lot of real | advantages for our case yet. I generally agree with your analysis. Using the initramfs system doesn't make sense for LEAF as it stands now. I would, however, be in favor of using a very powerful, but very small 'shell-like' scripting language (ie: forth) in the initramfs, with the 'applications' being scripts rather than biaries, which is what would make this idea attractive (at least to me). The downside is utilities like tar and gunzip would have to be coded in forth, which I haven't been able to find (or had the spare time to write). I think the entire extra 'footprint', including code to do tar, gunzip, and the forth interpreter itself could be squeezed into maybe 25K or so (assuming no re-use of the application scripts), meaning the 'redundancy' issue wouldn't be that bad, even for a floppy system. If you elected to reuse some of the scripted code, you'd only need a re-compiled interpreter for the appropriate libc, which for forth would probably mean 10-15K of 'redundancy'. ...of course, the probability of this actually happening is pretty close to zero (unless I somehow become independently wealthy!), but I still think it would be cool... - -- Charles Steinkuehler ch...@st... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBlbULywbqEHdNFwRAnLCAKChLtlI9drIqDN9zgUebloC2L6g7gCg3F3L Mu/XxB1VWh7XxrRsKhulVbM= =ajCI -----END PGP SIGNATURE----- |
|
From: Mike N. <mh...@us...> - 2005-08-20 16:35:04
|
On Fri, 2005-08-19 at 15:01, Charles Steinkuehler wrote: > I would, however, be in favor of using a very powerful, but very small > 'shell-like' scripting language (ie: forth) in the initramfs, with the > 'applications' being scripts rather than biaries, which is what would make > this idea attractive (at least to me). The downside is utilities like tar > and gunzip would have to be coded in forth, which I haven't been able to > find (or had the spare time to write). Charles, Does the initramfs cpio newc/crc buffer format fulfill the compressed file support? I'll look for forth gzip and tar source. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Charles S. <ch...@st...> - 2005-08-20 18:39:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Noyes wrote: | On Fri, 2005-08-19 at 15:01, Charles Steinkuehler wrote: |> I would, however, be in favor of using a very powerful, but very small |> 'shell-like' scripting language (ie: forth) in the initramfs, with the |> 'applications' being scripts rather than biaries, which is what would make |> this idea attractive (at least to me). The downside is utilities like tar |> and gunzip would have to be coded in forth, which I haven't been able to |> find (or had the spare time to write). | | Charles, | Does the initramfs cpio newc/crc buffer format fulfill the compressed | file support? It's not the initramfs system I'm worried about, particularly. It's the utilities we need to put INTO the initramfs in order to build a LEAF root filesystem image from the LRP files and configuration information (ie: LEAF.CFG and the kernel command line parameters). Several utilities are needed (look at /linuxrc for full details), but a lot of stuff could be worked around (ie: replace sed code with 'native' script) or are fairly trivial (ie: mount/umount and similar are pretty much just calls to the kernel with little user-mode function we'd have to duplicate), so it's stuff like gunzip and tar that I think will be hardest to replicate in a 'ground up' rework of the init scripts. | I'll look for forth gzip and tar source. Good luck! I've looked for these before, but have never been able to put much time into it. While you're "on the prowl", it might also be good to keep an eye out for lua or (other small script interpreter) versions of these utilities as well... - -- Charles Steinkuehler ch...@st... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDB3jvLywbqEHdNFwRArfJAKDPpcmvOkiXhcOECxejh323Qjn85QCgiMNV kH5Jj9koHlcQeuV0dgkPTMg= =j3iv -----END PGP SIGNATURE----- |
|
From: Mike N. <mh...@us...> - 2005-08-21 04:30:37
|
On Sat, 2005-08-20 at 11:39, Charles Steinkuehler wrote:
> | I'll look for forth gzip and tar source.
>
> Good luck! I've looked for these before, but have never been able to put
> much time into it. While you're "on the prowl", it might also be good to
> keep an eye out for lua or (other small script interpreter) versions of
> these utilities as well...
Charles,
Forth code is hard to find. The best I could locate is here:
http://forth.sourceforge.net/
http://cvs.sourceforge.net/viewcvs.py/forth/forth-repository/
I'll look for lua source next.
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Mike N. <mh...@us...> - 2005-08-20 16:27:42
|
On Fri, 2005-08-19 at 12:26, E.S...@in... wrote:
> But I agree, the initramfs approach would make a technical cleaner
> implementation. But it also means (because of redundancy and a bigger
> kernel (2.6)) a bigger base image. I also don't see a lot of real
> advantages for our case yet.
Eric,
There may not be at this time. However, I believe someone in the leaf
community should evaluate it now, and work on prof-of-concept/Alpha.
This would allow the rest of us to try it out, and see if it does have
long term benefits that aren't obvious right now.
Note: I'm not advocating Bering uClibc switch to initramfs.
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Homer P. <hp...@ho...> - 2005-08-22 17:25:25
|
On Sat, 2005-08-20 at 09:31 -0700, Mike Noyes wrote: > Note: I'm not advocating Bering uClibc switch to initramfs. Was chatting with Mike in IRC, and he suggested I post here instead ;) The Gentoo Network APpliance (GNAP) is an embedded distro using 2.6 and initramfs. I thought it might help with the conversion. See http://www.gentoo.org/proj/en/base/embedded/gnap.xml for more info. I'll crawl back into my cave and turn lurk mode back on now ;) -- Homer Parker hp...@ho... A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Maybe because some people are too annoyed by top-posting. Q: Why do I not get an answer to my question(s)? |
|
From: Mike N. <mh...@us...> - 2005-08-23 15:22:29
|
On Mon, 2005-08-22 at 10:25, Homer Parker wrote: > The Gentoo Network APpliance (GNAP) is an embedded distro using 2.6 and > initramfs. Homer, It looks like Bering uClibc for kernel 2.6. The only bad thing I see is GNAPs 16MB footprint. This is probably caused by the kernel and lack of busybox in GNAP. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Homer P. <hp...@ho...> - 2005-08-23 16:07:11
|
On Tue, 2005-08-23 at 08:26 -0700, Mike Noyes wrote: > Homer, > It looks like Bering uClibc for kernel 2.6. The only bad thing I see is > GNAPs 16MB footprint. This is probably caused by the kernel and lack of > busybox in GNAP. Yea, but might give some ideas on the conversion. Though, asides from a floppy, what can you buy today that wouldn't hold a 16MB image? -- Homer Parker hp...@ho... A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Maybe because some people are too annoyed by top-posting. Q: Why do I not get an answer to my question(s)? |
|
From: Mike N. <mh...@us...> - 2005-08-23 20:38:47
|
On Tue, 2005-08-23 at 09:06, Homer Parker wrote: > On Tue, 2005-08-23 at 08:26 -0700, Mike Noyes wrote: > > It looks like Bering uClibc for kernel 2.6. The only bad thing I see is > > GNAPs 16MB footprint. This is probably caused by the kernel and lack of > > busybox in GNAP. > > Yea, but might give some ideas on the conversion. Though, asides from a > floppy, what can you buy today that wouldn't hold a 16MB image? Homer, Not much. BTW, after reading some messages in gentoo-embedded, it looks like GNAP uses busybox -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: <E.S...@in...> - 2005-08-24 06:50:56
|
Mike, Homer, >> >> Yea, but might give some ideas on the conversion. Though, asides from a >> floppy, what can you buy today that wouldn't hold a 16MB image? > > Homer, > Not much. > LEAF runs in RAM, so it's not only a matter of 16 Mb storage but also the availability of internal RAM. This shouldn't be a problem in most cases, but if LEAF is ported to other architectures with limited RAM this could become a problem. Eric |
|
From: Erich T. <eri...@th...> - 2005-08-24 07:03:20
|
E.S...@in... wrote: > Mike, Homer, > > >>>Yea, but might give some ideas on the conversion. Though, asides from a >>> floppy, what can you buy today that wouldn't hold a 16MB image? >> >>Homer, >>Not much. >> > > LEAF runs in RAM, so it's not only a matter of 16 Mb storage but also the > availability of internal RAM. This shouldn't be a problem in most cases, > but if LEAF is ported to other architectures with limited RAM this could > become a problem. Indeed, and I am surprised noone ever brought this up. Currently LEAF (and probably other RAM based systems) is wasting RAM for storage of binaries , libraries and scripts, some of which are loaded only once. If we want to keep the RAM based architecture of the LEAF systems and reduce the RAM footprint I believe we need to restructure our packages so they can be held in a small number of loop mounted cramfs images. I believe we could reduce the filesystem footprint significantly. LINCE does this already AFAIK. Only the configuable files need to be held in a R/W filesystem. cheers Erich |
|
From: <E.S...@in...> - 2005-08-24 07:27:57
|
Hello Erich, >> LEAF runs in RAM, so it's not only a matter of 16 Mb storage but also >> the availability of internal RAM. This shouldn't be a problem in most >> cases, but if LEAF is ported to other architectures with limited RAM >> this could become a problem. > > Indeed, and I am surprised noone ever brought this up. Currently LEAF > (and probably other RAM based systems) is wasting RAM for storage of > binaries , libraries and scripts, some of which are loaded only once. If we > want to keep the RAM based architecture of the LEAF systems and reduce the > RAM footprint I believe we need to restructure our packages > so they can be held in a small number of loop mounted cramfs images. I > believe we could reduce the filesystem footprint significantly. LINCE does > this already AFAIK. Only the configuable files need to be held in a R/W > filesystem. > I don't follow you here. Why do you wan't to use loop mounted cramfs? Does it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based systems is that you can unmount the storage media. Besides the footprint of Bering-uClibc with base packages is only ~8Mb. Eric |
|
From: Erich T. <eri...@th...> - 2005-08-24 09:18:59
|
Eric E.S...@in... wrote: > > I don't follow you here. Why do you wan't to use loop mounted cramfs? Does > it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based > systems is that you can unmount the storage media. Besides the footprint > of Bering-uClibc with base packages is only ~8Mb. Yes, but look at it when it holds ipsec, ssh, samba, squid... A loop mounted cramfs looks (for read_only operations) exactly like a part of the file system tree. The benefit of this is that, even on ram, it cannot be trivially modified and it takes a lot less RAM space because it compresses its contents. For example if we had all the /bin in a cramfs called bin.cfs which would sit at / we could mount mount -o loop /bin.cfs /bin and the space needed by bin.cfs would be a lot smaller than if the individual files in /bin would be installed normally. The same is true for all read_only components, like /lib /sbin /usr/bin cheers Erich |
|
From: Natanael C. <ml...@ta...> - 2005-08-24 11:54:36
|
Erich Titl wrote: >Eric > >E.S...@in... wrote: > > >>I don't follow you here. Why do you wan't to use loop mounted cramfs? Does >>it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based >>systems is that you can unmount the storage media. Besides the footprint >>of Bering-uClibc with base packages is only ~8Mb. >> >> > >Yes, but look at it when it holds ipsec, ssh, samba, squid... > >A loop mounted cramfs looks (for read_only operations) exactly like a >part of the file system tree. The benefit of this is that, even on ram, >it cannot be trivially modified and it takes a lot less RAM space >because it compresses its contents. > > Are you really sure about that? I am not really familiar with how the tmpfs or ramfs works, but to me sounds logical that when you execute something on a tmpfs dist, the memory is never copied from ramdisk to RAM, because it is already in ram. It should be possible to run it from 1 single copy in RAM. But if you run it from a mounted loopdevice in ram, the code needs to be uncompressed and then executed. That means you will need a copy of the compressed code and one copy of the uncompressed. So if the compression ratio is 50% a compressed cramfs image on a tmpfs would take 50% more ram to execute the same code than if you just runs it "natively" from tmpfs. Again, I don't know how cramfs or tmpfs works so I could be completely wrong about this but I think is sounds logical. Also, the nature of Bering uClibc is that you only need to unpack the needed packages to RAM, so you are probably using the packages that are extracted to RAM. On a normal disk based system, the linux kernel would cache the used executable data from disk to RAM so the memory will be used anyway - but the kernel has the option to free it if needed for other things. When running from RAM you will only prevent the kernel from releasing the memory to use on other things wich guarantees you an ultrafast system. Adding a swap disk is also an interesting topic... You will save RAM when mounting a cramfs image on cdrom or mount a disk, but the difference is maybe not so big as you might think. -- Natanael Copa |
|
From: Erich T. <eri...@th...> - 2005-08-24 12:31:32
|
Natanael Copa wrote: > Erich Titl wrote: > > >>Eric .. >> >> > > > Are you really sure about that? I am not really familiar with how the > tmpfs or ramfs works, but to me sounds logical that when you execute > something on a tmpfs dist, the memory is never copied from ramdisk to > RAM, because it is already in ram. It should be possible to run it from > 1 single copy in RAM. If this is true, then the entire idea is wrong. I doubt though, because the program loader does more than just make a copy of the executable. It needs to dynamically link to libraries, e.t.c. I am not sure it meddles with the intricacies of a file system. > > But if you run it from a mounted loopdevice in ram, the code needs to be > uncompressed and then executed. That means you will need a copy of the > compressed code and one copy of the uncompressed. True, but see above, maybe someone can shed a light on this. One thing is sure, if you compress the binary it needs to be uncompressed before execution. > ... > > You will save RAM when mounting a cramfs image on cdrom or mount a disk, > but the difference is maybe not so big as you might think. This may defeat the read-only methods implemented by disabling ide drivers. cheers Erich |
|
From: Natanael C. <ml...@ta...> - 2005-08-24 14:33:54
|
Erich Titl wrote: >Natanael Copa wrote: > > >>Are you really sure about that? I am not really familiar with how the >>tmpfs or ramfs works, but to me sounds logical that when you execute >>something on a tmpfs dist, the memory is never copied from ramdisk to >>RAM, because it is already in ram. It should be possible to run it from >>1 single copy in RAM. >> >> > >If this is true, then the entire idea is wrong. I doubt though, because >the program loader does more than just make a copy of the executable. It >needs to dynamically link to libraries, e.t.c. I am not sure it meddles >with the intricacies of a file system. > > I dont have time for reading about memory management in Linux right now, but AFAIK the executables and libraries are mmap'ed. So the executable is not read into physical RAM until the memory page is touched. Also the dynamic libraries shares the memory so there should not be more than one copy of the executable libray in RAM anyway. So I believe that a shared library on a tmpfs exist only once in RAM. Even if you fork a process, there will only be 1 copy in RAM - until you write to that memory page. (google on "copy-on-write") It would really not make any sense to copy a mmap'ed executable from RAM to another place in RAM, 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...:) >>But if you run it from a mounted loopdevice in ram, the code needs to be >>uncompressed and then executed. That means you will need a copy of the >>compressed code and one copy of the uncompressed. >> >> > >True, but see above, maybe someone can shed a light on this. One thing >is sure, if you compress the binary it needs to be uncompressed before >execution. > > http://google.com/search?q=linux+memory+management is probably a good start. -- Natanael Copa |
|
From: Erich T. <eri...@th...> - 2005-08-24 15:25:16
|
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. cheers Erich |