(Now we're getting a bit too far off topic, I think but oh well...) Zachary Kotlarek wrote: > > On Oct 27, 2009, at 11:08 AM, Bryan Kadzban wrote: > >> Actually, you don't need it for that, either. Mostly because the >> format of the cpio archive that the kernel expands is rather >> simple, and because the kernel includes code to build this already. > > The kernel make system includes the ability to translate an index > file into a cpio archive.
Right, and the program used for this can take this index file via stdin. So I just use that. See mkinitramfs.in and support/mkinitramfs/gen_init_cpio.c at http://www.linuxfromscratch.org/~bryan/lfs-initramfs-1.0.tar.bz2 for how it works. :-) Unfortunately some of that did end up requiring a separate build tree (IIRC, this was only to get selective-modules working, since I had to run depmod somewhere), but this doesn't include everything. It's only the files that need changing, or that need to be in a separate tree for some other tool to work with. I believe it's only modules, modules.dep, and udev rules, but don't remember for sure anymore. > But that's a little cumbersome if you don't use exactly the same set > of files with each build. You could use some sort of script to > automatically build an index from a directory tree, but that sounds a > lot like the archiving tool you're trying to avoid, except more > poorly maintained. Yep. Or you can create a list of everything required (as far as tools go), then build the list of required libs from those binaries, and then add a bunch of random modules as well, and feed this list into the gen_init_cpio program, gzipping its stdout. > I'm also not sure you can build an external image with the > kernel-based cpio tools, Not directly. But if you pull the code out of the kernel... :-) > And there's certainly no way to unpack and re-pack an image if you'd > like to make a change. Right, this is the big problem with a setup like this for people that want to change the setup after it gets built. (This is also why I broke down and installed cpio myself when testing this lfs-initramfs package. I needed to verify what files got put where, and their contents. Though I never used it to recreate an archive.) But when building that package, I tried to make it never need to be changed after running mkinitramfs; certainly it works for me. :-) > I'm not saying that LFS necessarily needs cpio as part of the base -- > frankly I'm of the general opinion that LFS should not try for LSB > compliance other than maybe mentioning how you *could* do it with > BLFS and the like. Which seems to be what's happening. (This is fine by me, too.) > I'm just saying there's a fairly common (at least among users that > build their own kernels and have non-trivial hardware rigs), non-RPM > use for cpio archives. Yeah. Pulling bits out of the kernel and reusing them is possible, but probably not the best thing for everyone to do independently. (Then again, that package may not be great for everyone to use, either. If a random distro's package could be easily made to work, that might be better for some cases, I'm not sure. It seemed at the time that most of the distro packages had accumulated a *lot* of cruft -- and then this package started accumulating cruft, too. Oh well. :-) )
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
