Hi Charles, El Lun 08 Mar 2004 23:31, Charles Steinkuehler escribió: > I'm back from my business trip, and have begun work on cleaning up the > linuxrc script used for Bering, but I have a few questions/issues for > the Bering maintainers: > > - One of the first things the scripts do is run "busybox --install -s" > to make symlinks for busybox, but these are already stored in the > initial ramdisk. The symlinks don't take a lot of space (each is a > minimal tar entry (512 bytes IIRC), which should compress well being > mostly zeros), but IIRC, the code to get busybox to build symlinks is a > configurable option. I can see doing one or the other (making symlinks > with busybox, or storing them in the initrd), but doing both seems a > waste. Any comments on why this is done this way? I figure it's likely > due to the way initrd is backed up (which I haven't crawled through yet).
Yes, I agree, it is a waste. I think is better choise to run "busybox --install -s" (maybe to avoid accidental removing of the symblinks?) > - The boot= kernel command line option will be going away, as previously > discussed. Excuse me, Why? > - There will be a new kernel command line option which will (optionally) > tell the init scripts where to find files that override any supplied on > the kernel command line. I need a name for this option (I'm proposing > LEAFCFG=), as well as name(s) and format(s) for the new file(s). In > addition to the current lrpkg.cfg and pkgpath.cfg files, I'd like to be > able to control the ramdisk sizes from a configuration file > (ramdisk.cfg?). I'd propose this file be parsed as a script, and simply > contain some variable assignments (along with comments), something like: > > # Set root ramdisk size > SYSTSIZE=12M > > # Set log ramdisk size > LOGSIZE=4M Yep, this is a great idea. > NOTE: I'd like to see a consistent format for the varaible names (ie: > maybe ROOTSIZE and TMPSIZE). Any preferences on > > - Having a configuration file that is simply included as shell script > opens up some interesting possabilities. For starters, pretty much any > options could be dumped into this file, allowing something like: > > # Spit out extra info > VERBOSE=1 > DEBUG=1 > > ...and even the inclusion of the lrpkg.cfg and pkgpath.cfg > functionality. So...is there any interest in making an 'all-in-one' > configuration file (ie: adding support for setting PKGPATH and LRP > variables), and if so, should support for the existing pkgpath.cfg and > lrpkg.cfg files remain? > > Sorry about the length, but I'm not wanting to step on anyone's toes > with any modificationss I make. If I'm asking too many questions, feel > free to tell me to just shut up and code, then rip holes in whatever I > wind up posting (a lot of times, this sort of stuff is easier to comment > on once there's something concrete to analyze and complain about :-). > > Thanks in advance for any comments! Thanks to you. -- Juan Jesús Prieto - Consultoría TI [EMAIL PROTECTED] http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
