From owner-freebsd-hackers Tue Mar 21 21:55:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from guardian.sftw.com (guardian.sftw.com [209.157.37.25]) by hub.freebsd.org (Postfix) with ESMTP id 10EEA37BD89 for ; Tue, 21 Mar 2000 21:55:48 -0800 (PST) (envelope-from nsayer@sftw.com) Received: from yoda.sftw.com (yoda.sftw.com [209.157.37.211]) by guardian.sftw.com (8.9.3/8.9.3) with ESMTP id VAA07257 for ; Tue, 21 Mar 2000 21:55:40 -0800 (PST) (envelope-from nsayer@yoda.sftw.com) Received: (from nsayer@localhost) by yoda.sftw.com (8.9.3/8.9.3) id VAA56886 for freebsd-hackers@freebsd.org; Tue, 21 Mar 2000 21:55:39 -0800 (PST) (envelope-from nsayer) Date: Tue, 21 Mar 2000 21:55:39 -0800 (PST) From: Nick Sayer Message-Id: <200003220555.VAA56886@yoda.sftw.com> To: freebsd-hackers@freebsd.org Subject: md_image compression? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sort of thinking in my head about adding the ability for the md driver to handle gziped images. md's drvinit() looks like the perfect place to do this. if strcmp(type,"md_image_gzip") then gunzip the image and so on. Obviously this trades RAM for disk space. The target implementation is the i-opener -> X terminal transmogrification. I think I can cram the whole thing into the 16M flash card, and with compression of that image, I can cram a lot more. To implement it, I have some questions: 1. Is there a way to de-allocate or otherwise reuse the original compressed image after the unzip is finished? 2. What is the best strategy for allocating the output image? malloc(9)? 3. This would effectively add libz to the kernel. Does anyone object, given the proviso that this whole mess would hide inside of an option (MD_PRELOAD_GZIP springs to mind)? Perhaps instead the md unzipper could be loaded as a module. The module could be thrown away using the same mechanism as #1 once the decompression is finished. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message