Resend to the list, without attachment now
Charles, > > But can't we remove the "boot=" line althogether? I know it's used as > > backup device but if we f.e. make the last device in the PKGPATH line > > the backup device a lot of script lines can be removed. The boot= > > line isn't used for the boot device for a long time anyway. > > I don't think backward compatibility is a big issue. > > While I think the 'boot' name is somewhat misleading, there is still the > problem of how to override settings provided on the kernel command line > when booting off a read-only media like a CD-ROM. I 'hijacked' the > boot= setting for this purpose in Dachstein (it's really more of a > 'configuration_files=' setting now, espeically in Bering since it's not > automatically added to the package path). > > I can see arguments both ways for doing away with the boot= setting. > Even if used on something like a CD-ROM, it's still hard-coded, so > anyone w/o a floppy drive will have to burn a new CD anyway (unless > their boot= device is found 'automagically' by the linuxrc scripts > 'automount' function). > The 'automount' function is something I rather see disapeare. Now that the various LEAF branches can boot of virtual anything, the 'root.mount' list is outdated and it's a pain to maintain it for every possible bootdevice. You have to define the bootdevice anyway and it's better to give an error when it fails than make it work sometimes 'automagically'. This will speed up booting and saves some lines in linuxrc. As you can guess by now, I like a clean and small linuxrc without a lot of bells and whistles ;-) > On the other hand, it's nice to have a way to explicitly list where the > configuration files are coming from (espeically on something where > security is as important as a firewall), even if you have to burn a new > CD-ROM (or build a new ROMFS image) to change it. > > In my mind, the ability to explicitly declare a source for the > 'override' files (pkgpath.cfg and lrpkg.cfg) is important enough to > warrent a specific kernel command line parameter. I could, however, be > easily talked into migrating the package path functionality of the boot= > setting into PKGPATH, doing away with boot= entirely, and creating a > *NEW* setting for the configuration aspect of the boot= setting (maybe > LEAFCFG=). In fact, the more I think about it, the more it seems like > this is the 'right' way to proceed. > My vote would go to this approach, I think this is the time to do it right. Bering-uClibc uses lrpkg.cfg exclusively, so kernel command line length isn't of great concern for this branch. I don't think we should have any problems using pkgpath.cfg also, this makes the choice and configuration of bootloaders easier. But I can't speak for other branches ofcourse... Why provide different ways of setting options? I think providing one way to set options is enough and clearer to an user. > If kernel command line length is of great concern, it would be possible > to structure the LEAFCFG= setting so it could (optionally) be added to > the package path, if desired. Maybe something like: > LEAFCFG=+/dev/fd0:msdos > > ...to add the LEAFCFG device to the package path, and w/o the '+' > PKGPATH is processed as usual? > That's an option, but not necessary in my opinion. For what it's worth, I attached some work I did on linuxrc, mainly to understand how it works, make it simpler and to try some ideas. It has a lot of comments in it and probably a lot of bugs also... Eric Spakman ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
