The 'zdrv' is back

Those who know a bit about Puppy's history will know that the 'zdrv' had its period of glory. For various reasons I went back to putting all the modules and firmware into the main SFS file, and did away with the 'zdrv' SFS file.

However, I implemented code in Puppy4 for it to return, but in an improved manner. It now loads as a layer in the Unionfs layered filesystem at bootup, so is continuously present while Puppy is running.

As the Woof builds are bulging a bit, beyond 100MB, I decided to reintroduce the zdrv. What this does is take out all the modules and firmware to the 'zdrv' SFS file, and this is quite a lot, the zdrv SFS file for my 2.6.27.4 kernel is 18.3MB. The main SFS gets copied into RAM at bootup, and being smaller frees up some RAM for general use. On a 256MB system, 18.3MB is significant. The 'zdrv' SFS does not have to be copied to RAM, just mounted from where it is -- in the case of a CD, the normal behaviour is that it gets copied to the same place as the 'pupsave' file so gets mounted from there, so freeing-up the CD.

In Puppy4, if anyone examined the 'init' script, you would see that I had reserved /dev/loop3 for the 'zdrv'. Note however, now that I have actually done it, I found a couple of bugs, now fixed.

So, alpha4, due out Real Soon Now, will probably be built this way. Note, the 'zdrv' file is now named to fit in the 8+3 format and cram in as much information as possible. For example, in my latest build, it is named 'zu460274.sfs' -- the first letter identifies it as a zdrv, the second as an Ubuntu compatible-distro-build, the 460 is the version number, and the 274 is a reduction of the kernel version (from 2.6.27.4).

---

Comments

zdrv return
Username: dogone
I understand your interest in keeping Puppy's memory footprint small. I am a bit concerned about users having to keep track of another puppy file. Is the hassle/risk ("zu460274.sfs" looks a lot like "za480274.sfs") worth the benefit? RAM is rarely a serious constraint, even in older "pup-patible" hardware. Yes, "100MB" is enchanting. But I would rather give up a few MB of RAM than to have to worry about "that other file". Puppy's simplicity is something very precious.

Kernel 2.6.29 - upup
Username: Terryphi
"Are you not sticking with kernel 2.6.29 for upup? I have been very happy with it.

"RAM is rarely ..."
Username: GreatnessGuru
"dogone saith: "RAM is rarely a serious constraint, even in older "pup-patible" hardware." In apparent, but fruitless, preventive clarification, Our Fearless Pack Leader saith: "On a 256MB system, 18.3MB is significant." On my "older" 64 MB Gateway 2000, 18.3MB is Four Times more "serious"/"significant". So, I say: RAM is Always a serious constraint, Especially in older "pup-patible" hardware. Thanks so much, Barry, for thinking of us "older" puppy lovers. Eddie Maddox Inwood IA USA

Yay!
Username: PaulBx1
"Always did think zdrv was a good concept. I hear the point about simplicity, but the advantages far outweigh this drawback. Windows refugees, with thousands of files on their hard drive, are not going to carp about a single additional file for puppy. However I suggest a change to the filename to make things a bit more transparent for users: "pupzu999.sfs", see explanation below: "pup" to make it clear this is a puppy file, and will be seen in close proximity with the pupsave and pup_999.sfs in Rox et. al., making puppy file management simpler. "z" meaning zdrv as you specify "u" meaning ubuntu build as you specify "999" being a number that starts at zero and increases for each zdrv released, whether for different puppy version, different kernel, or zdrv fix. There must be a document somewhere that makes the correspondence between zdrv number and these other things. This may sound like an additional bit of work, but it adds flexibility and anyway even your current filename specification requires explanation. Instead of explaining what "zu460274.sfs" means, why not just say "Go look at /root/zdrvinfo.txt, which explains everything"?

Tags: woof