Hello Charles,<snip>
I initialized the package path to the boot= device for the following reasons:An extra reason to change the behaviour, the less hacks the better I think.
- Everything works as before if you don't include a PKGPATH setting in the kernel command line or provide a pkgpath.cfg file on the boot= device, ie: backwards compatability.
- There's no real need to specify the same device twice, which wastes kernel command line space (limited to 256 characters).
NOTE: The DoC 'hack' would *NOT* have been required, if the old Dachstein method of including the boot= device in the package path had been implemented.
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).
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.
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?
Before I 'fix' this in the new linuxrc scripts I'm working on, I want to make sure it's not supposed to work the way it does for some reason I don't fully understand.I don't know of any reasons.
Thanks for your feedback.
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- 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
