when booting from floppy disk. I don't believe that would be much of a selling point.
Loading the modules from hard disk would have to be done before booting from floppy.
Well, this is pretty much what System-Startup does in 3.2. The problem is, you cannot really load anything from harddisk without the modules initialized you need to run the harddisk, which is already quite a bit. Actually, exec, expansion, timer, misc, disk, utility and dos are needed, also graphics and intuition (and probably some other minor ones I forgot).
I wonder if this 'list of modules' could be stored on a designated RDB? Or at least a flag on the RDB which tells Kickstart that 'Modules are on this drive/partition!' The Kickstart could then look for valid modules on that drive and load them, all before the system comes ready...so no reboot would be required and it's all done before even booting from the hard disk (ie. even before the Startup-Sequence).
I wonder what the benefit of this would be. The only additional module you need to load them from the regular file system is the file system, and *that* can sit in the RDB anyhow by tradition. The drawback of having modules in the RDB is that you do not see them, you also need dedicated tools to manipulate them there, and you run into potential compatibility issues with the firmware of the drive - which is responsible for handling the RDB (and not the kickstart, note well!).
So, in a sense, we are with 3.2 exactly where you propose us to be, except that there is a "default module" in ROM as well, which can be overridden by a RAM module. This only works for modules that are not initialized for accessing the harddrive, of course (intuition is some special exception, but the 3.2 intuition received a new feature, namely it is able to be shut down afterwards for getting replaced). And except that the modules are stored in the regular file system, so they are easy update and manipulate.
The only components you could remove from ROM because they non-essential for booting are mathffp,mathieeesingbas and audio, but again, some firmware might depend on them being available for their boot process because they have been in ROM, so I was really hesitating to make the change. They can be updated by System-Startup, of course.
There is no fine-control for this, but there will be an on-off switch in the boot menu to avoid trouble in case you accidentally trashed one of the replacement modules on disk, i.e. there is a fail-safe fall-back mode "rom boot only" mechanism. User programs could jump in to create a per-module switch, simply by renaming compoents on disk.
From a cold boot, can 3.2 boot from floppy disk with hard disk modules already loaded? The flag (which could point to a volume where modules are stored) if not stored on the RDB, could be stored just after the RDB. Isn't there a 'reserved blocks' feature or something in HDToolbox I seem to recall? Upon cold boot the system could read this flag, load the modules and then boot from either DF0 or whatever else is available. The bootmenu for example (if the imaginary 'Modules button' is selected) could list the modules (from the designated volume) and the user could be given individual control over them (Module version number could also be listed). Regarding the flag again, if it's not found it wouldn't matter (ie. a 2.x or 3.1 drive attached).
Or, preferably perhaps, it could do all the same as above, but forget the flag, and just search for the modules from the disk with the highest boot priority (modules could even be searched for from floppy if a devs/modules drawer is found). Obviously , if no disk is inserted in DF0 it will next look in DH0 devs/modules (providing that DH0 has the next highest boot priority).
If, for some reason someone connects an additional hard disk or has an additional partition/volume with a higher priority and they don't want the modules loaded from there (ie. it has the devs/modules directory also), then there could be a little config file in devs/modules of the unwanted volume which could be read before the modules are loaded which simply has the the real volume/partition from which you want the modules to actually be loaded from - and this would also be reflected in bootmenu). Or, I suppose temporary control instead could be had from within the bootmenu if such a problem arises.
All of this I mention because I was thinking of the system being up-to-date and ready, ready even from cold booting into a floppy disk (or any other boot device).
