Date: Mon, 2 Oct 1995 22:24:11 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, julian@ref.tfs.com Cc: davidg@Root.COM, hackers@freefall.freebsd.org, jkh@time.cdrom.com Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Message-ID: <199510021224.WAA26089@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Surely there is more of a problem fitting everything at runtime than just >> loading it? >The limiting factor is either fitting the compressed file between >3MB and the end of RAM, or fitting the output of the decompression >between 1MB and 3MB.. I've seen both fail at various times.. The packing problem could be reduced by keeping the mfsroot in a separate file or on a separate floppy, but these methods are currently too hard, and if we go to a separate floppy we might as well forget about compression (at least while the kernel and the mfs still fit on a 1200K floppy). >You could relocate the decomp routines to < 640K and run them down there >and let the decompressed output overwrite the start of the compressed version >(and hope it never catches up with the read pointer..) >I think the problem at the moment is htat the compressed binary runs >past 4MB. Relocation of code would be messy. Relocation of data is easy. If the last problem is the only one, solve it by copying the last few hundred K of the compressed binary to low memory while you're decompressing the first few hundred K, then put it back. This could be combined with overwriting to increase the chance that the write pointer never catches up. The current memory map at decompress_kernel() time seems to be: 0: reserved 4K: free 64K: boot program (need to preserve a little of its data) 128K: free 320K: malloc heap nnnK: end of low RAM; start of memory abused by malloc if nnn < 640 640K: bus memory There is a block of 192K and a block of 316K or more could be arranged. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510021224.WAA26089>