Date: Fri, 06 Feb 1998 20:53:59 -0800 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: dyson@FreeBSD.ORG, mike@smith.net.au, abial@nask.pl, freebsd-current@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Custom init(8) (and some ideas) Message-ID: <199802070454.UAA03722@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 07 Feb 1998 04:34:09 GMT." <199802070434.VAA25379@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> What is the compression table flush boundry? You *could* use the > gzip'ped file as a swap store, *if* you created pages out of the > file on the flush boundry, since you could re-decompress the needed > pages by restarting from that point. It's not quite that simple. From /usr/src/lib/libz/algorithm.doc: ---8<--- Literals or match lengths are compressed with one Huffman tree, and match distances are compressed with another tree. The trees are stored in a compact form at the start of each block. The blocks can have any size (except that the compressed data for one block must fit in available memory). A block is terminated when deflate() determines that it would be useful to start another block with fresh trees. (This is somewhat similar to the behavior of LZW-based _compress_.) ---8<--- You would have to scan the entire image to locate the compression blocks, which would be a chore. > This would require (basically) a gzip-pager. You would also need > to make an map (probably an RLE 0/1 bitmap) to know how many full > and partial pages each decompressed to, and handle the section > boundries (since they would probably not decompress to even page > boundries). A table of region lengths would be more compact, but perhaps slower to traverse. This would be another one of those fun-but-distracting projects for a relatively new kernel hacker. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802070454.UAA03722>