Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Mon, Mar 10, 2008 at 4:58 PM, Martin Hejl [EMAIL PROTECTED] wrote: oops - sorry Hi Nicol, make that Hi David I wasn't trying to make any point; just sharing my experiences that (1) tinygentoo image was easy to work with for creating uclibc-linked this and that (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is (I guess I'm also sharing that the existing build environment had too high a learning barrier; that the gcc.lrp package did not appear to exist on the .iso; and that a build environment lrp might be a good idea; that altogether I found Bering to be organized well) Also you seem to have misconstrued my size matters to mean something different from what I intended. No harm, no foul. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. That's not correct. Indeed you can make a choice to include the initramfs (not initrd) into the kernel, but it has no technical advantage besides having only a kernel instead of a kernel and an initramfs.cpio. The reason to have both options has to do with GPL and including non-GPLed modules. Besides it's easier to have a seperate kernel and initramfs if you want to support multiple boot devices and also keep size down. In both cases you have to do a switch_root (not pivot_root which was the case with kernel 2.4) to free the initramfs and start init. So you always have a file system, ramfs, even if you embed the whole system in the kernel and you have to do a switch_root to give init the control and do some other housekeeping. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is Well, one downside of this approach is that you cannot control the size of the root-fs by a variable in leaf.cfg, as we can do now. Boxes that have a lot of packages loaded need a bigger root fs, old boxes with little RAM need a smaller one. It seems difficult to me to decide which root-fs size works for everybody. (I guess I'm also sharing that the existing build environment had too high a learning barrier; I guess it does - but I'm afraid the one's who have written it or have used it for several years are not the perfect candidates for writing easy to understand docs that explain things to people new to the build environment. It surely has its rough edges - but it does what it needs to do most of the time. that the gcc.lrp package did not appear to exist on the .iso; Yup, that's correct. and that a build environment lrp might be a good idea; I disagree - but if somebody builds a gcc.lrp, it can be put into the contrib area, and people can decide for themselves if they need it or not. Also you seem to have misconstrued my size matters to mean something different from what I intended. It appears that I have No harm, no foul. That's good. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is An added note: Like Martin explained it has to do with system memory. It is theoretical possible to use the initramfs ramfs as root filesystem, but it has a big drawback. In the initramfs we create three dynamic tmpfs (a superset of ramfs) for root, tmp and log with an upper memory limit set, which can be defined in leaf.cfg. This means that, when correctly set, that growing files (like logfiles) can't crash the system if the total size is beyond the physical memory size of the system, because of the upper limit. This isn't possible with the simple initramfs fs. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
