Many "?drv...sfs" files, another hack to the 'init' script

[gyrog]

I've just committed some patches to the 'init-experiment' branch. This is also announced on the Puppy forum here.

The point of this fairly large hack of 'init' is to change the way it sets-up the base stack using the ".sfs" files. It processes each file completely one at a time, from begining with just an identifying letter, to the ".sfs" files mount-point being in the stack. The procesing of a boot parameter and the decoding af any UUID or LABEL are now just a part of the process inside the loop. Much of the code up until the calling of the 'setup_onepupdrv' function, has been replaced. Appart from the changes to the definition of "?drv...sfs" files, I much prefer the process represented by this code, rather than processing all boot parameters, decoding all UUID's and LABEL's, and then handling the ".sfs" files one by one.

In this patched version the "drv"'s are now defined by 2 lists of prefixes, $APPEND_DRVS and $PREPEND_DRVS, which get prepended to "drv_${DISTRO_FILE_PREFIX}_${DISTRO_VERSION}.sfs" to form the filenames of the ".sfs" files. Hence kind of unlimited. Note: Even though the 'puppy...sfs' is notionally the 'p' ".sfs" it is processed independently, before the 2 loops. (One for $APPEND_DRVS, and one for $PREPEND_DRVS.)

To make things easier for users to change which "?drv...sfs" files are loaded, any 'BOOT_SPECS' file in the installation directory is processed after the 'puppy...sfs' file has been successfully loaded. This 'BOOT_SPECS' file can define $APPEND_DRVS and $PREPEND_DRVS for the following 2 loops.

This requires a patched 'sfs_load' to cope with the possibly many new "?drv...sfs" files, which I have also committed to 'init-experiment'.

The 'init' script also contains a patch to mount a tmpfs directly at '/tmp'. This requires a patched 'rc.sysinit' to get it to adjust the size of the tmpfs at '/tmp' rather than the tmpfs that contains only the ".sfs" files. I haven't committed the patched 'rc.sysinit' yet.

I've placed this stuff in 'init-experiment' just so folk can see the code. I don't expect this to be merged to 'testing'.

[gyrog]

Patched 'rc.sysinit' now committed.

[gyrog]

Patched 'isoboot' so it works with this patched 'init' script.

[01micko]

@gyrog I just pulled the branch init-experiment and merged in testing and there are no conflicts. I can either 'push' it here or wait until you are ready, or you can do it.

git checkout testing
git pull
git checkout init-experiment
git pull # ensuring it's up to date
git merge testing # just save the commit file
git push

Just to refresh your memory :memo:

EDIT:

I don't expect this to be merged to 'testing'.

No problem, but keeping the init-experiment branch up to date with testing allows 'woofers' to build and test with the latest up to date builds.

[gyrog]

Thanks, I get you point about keeping it up to date with 'testing' just in case anyone should try "woofing" it.

I had assumed that 'init-experiment' had long since bit the dust, but when I noticed it was still there, I thought it would be a good place to store this stuff so anyone can have easy access.

The project is still really at a "proof of concept" stage, and there are likely to be many fixes, and many of the patches will be wrong. And then if this stage works, some of the remaining code should be cleaned up to take advantage. The ineterface between the "new" and "old" is still a little "contrived".

My thought at this time, is that rather than ever "pushing" this most likely very messy set of patches to "testing", to take the end result, and generate a set of "clean" patches to "testing", should that point ever be reached, and then get rid of "init-experiment". For now I will just keep pushing stuff to 'init-experiment'.

[01micko]

No worries, but should you want to update and merge testing the snippet I posted above will do it. Cheers.

[gyrog]

For what it's worth, the first version is done, and works with UPupHH+D, (well it does on my machine).