If you're using the loader, don't bother. It'll do this for you as it
loads the image. See eg. how the install floppies work.
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
