Adding more drives to Puppy

[amethyst]

I'm talking about a bdrv, cdrv, ddrv, etc. Some of us already have this envoked with "experimental" initrd changes. As far as I know the standard Puppy issue still only has the implementation of the adrv and ydrv, this may restrict user options somewhat. So this is my suggestion for developers - implement these additional drives for the standard Puppy issue.

[rockedge]

didn't @taersh put something together that modified Puppy so one could use the whole alphabet of "drv" names?

[amethyst]

A few of us I have experimented with this before. I have my own modified initrd script with all these addiditional drives (I don't use it a lot personally) but I think there is a need for it for some users so why not implement the feature for new Puppys? It involves modification to the initrd script, sfs_load script (I didn't change sfs_load for mine) and DISTRO_SPECS. I use basically the same initrd for all my Puppys, I just change the DISTRO_SPECS section for every Puppy. Here is a download link for my initrd.gz just as an example of my effort: https://drive.google.com/file/d/1GUGi5g ... sp=sharing

I've also experimented with name changes for the drives which can be done doing the changes in DISTRO_SPECS. For example: bdrv_Palemoon.sfs. This way you can identify with the contents of the drive that is being loaded.

[rockedge]

In KLV and WDL (WeeDog) it's determined by adding 2 digits to the front of the file name. Also determines the order of the SFS (also uncompressed directories will load this way). One can use up to 100.

Any name will work as long as the 2 digits are in the prefix. 55load-me-at-boot.sfs would work.

I do like your ideas @amethyst and agree that this feature should be incorporated into Puppy Linux.

[amethyst]

It's also possible to stipulate which of these additional drives to load at startup and which not to load, and so on.....

[rockedge]

With KLV and WDL removing the 2 digits in the file name prefix or something like no-55load-me-at-boot.sfs would prevent the SFS from loading at boot, which can after the system is up, be loaded on the fly with SFS-Load-GUI

Perhaps some mechanism added to puppy so with a name prefix like d_drv-Textmaker2019-amd64.sfs or s_drv-Textmaker2019-amd64.sfs where the s_drv- is the prefix, indicates load this SFS during system boot. Where the layer position of loading is determined by the alphabetic order indicated in the *_drv- file name prefix.

Drawback is in this scheme it is limited by 26 letters in the alphabet. We could consider adding the ablilty to read names like aa_drv-some-package.sfs to double the count to 52 SFS files.

In KLV, WDL and all the WeeDog's up 100 sfs files can be loaded in this way. One hundred is the limit chosen at design time, but I think that could be increased.

[williams2]

names like aa_drv-some-package.sfs to double the count to 52 SFS files

26 * 26 = 676

[rockedge]

@williams2 Excellent point. I did not take in account aa_, ab_, ac_,ad_,...............so on and so forth.

It seems 676 would be an acceptable amount, if the altering of the initrd.gz was not too involved to implement the code to do it. @wiak has an excellent mechanism for the WDL initrd and the skeleton version of that initrd.gz, which is in KLV-Airedale, but these are using overlayfs where as Puppy Linux would need a similar mechanism using AUFS.

[amethyst]

It's not necessary to extend implementation of the additional drives to a ridiculous number (although it's possible, it's not practically necessary). The current scenario of only having an adrv and ydrv available is inadequate though.

[amethyst]

Another thing not related to the topic but i.r.o general running of Puppy. Many users have lots of RAM available. I was wondering about the copying to RAM option at bootup. What happens currently is that the sfs file is copied in its compressed state. This results in slightly faster operation but the thing is that the SFS file still needs to be decompressed to access the files (well, that is how I think it is). So, how about copying the files to RAM in an uncompressed state (in other words decompress the sfs first) at bootup. Logic would suggest that this will speed up things even more.