Fordi
Group: Members
Posts: 90
Joined: April 2004 |
|
Posted: Feb. 28 2005,07:08 |
|
cloop has a 2G limit to uncompressed size, I think, and you are limited to 8 cloop devices You can get up to 255 normal loop devices, too. (to unlock the extra loops requires: -A change to the boot parameters (add max_loop(s?)=n) -An on-boot script that will create the devices necessary to handle the extra loops (makedev is not available on the core DSL distro, so it would require a script in /etc/init.d, a link to that script in /etc/rcS.d, and a copy of makedevs from the dsl-utils.dsl package, all stored within a customized .dsl pack)
I did a little research on this a short while back and had someone unveil the key to this trick in the "Talk" page.
And, yes, this will be in my own microlinux distro (so far, I've got a pre-beta running to X from eight or so megs, and is compatible with .debs, .dsls, .ucis, .rpms, dsl-type .tar.gzs (must be renamed to dtz for getting-there's sake), my own sqsh (kept cos it's simpler to just use the loops as sqshfs than to translate the loops to cloops - it has the same directory limitation as uci) and sqx (same as sqsh, but links into the filesystem proper) formats.
Running to X, but with little else but the WM (which is post-boot mounted and configurable from outside the main FS file. I currently have Fluxbox, KDE, xpde and icewm).
Yes. KDE. As an sqx, and eating about 10% of the filehandles (1k blocks in a quick ramdisk kernel hack greatly reduces the amount of space utilized by symlinks. To be honest, I don't know why one has to have blocks from RAM. Sure, 1 Byte blocks would reduce performance - too many system calls - but 1k works fine on my 500 MHz machine.) I also had to do a dirty little hack to the uClibc that I've been using. If a symlink is opened for write, it checks if the target is read-only, and if so, replaces the symlink with a copy of the file and reopens it, returning the file handle. Recursive function, nice and elegant. Even detects looped links and complains about them. The upshot is that the user can run an app like KDE mostly from a read-only source, but in the even the WM has to write to its own FS links, it can, and does, nice and transparent-like.
So yeah. Nice stuff. Too bad it's still buggy (mostly getting apps to work is similar to pulling teeth. Things are supposed to work all transparently, but the second you install a decompression-type package - like a dsl, tar.gz, rpm or deb - over a big linked app, things get all funny. S'probably from RAM use, so I think I just have to have a target machine calculator. (Idiot light-type + details. you know. OK! This disc will run fine on the target machine, WAIT! This disc will boot fine, but initializing too many of the optional apps will crash your machine, STOP! This disc will not boot on your target machine)
Sorry I been so quiet lately. While I've been doing that, on my Windows machine, I've been toying around with GBA development using HAM. Fun stuff, really. Nearly have a port of the old DOS game, Brix, completed.
|