From owner-freebsd-hackers  Thu Aug 31 13:58:17 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA23107
          for hackers-outgoing; Thu, 31 Aug 1995 13:58:17 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA23084
          for <hackers@freebsd.org>; Thu, 31 Aug 1995 13:58:14 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id NAA00679; Thu, 31 Aug 1995 13:57:54 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199508312057.NAA00679@ref.tfs.com>
Subject: Re: kernel size
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Thu, 31 Aug 1995 13:57:53 -0700 (PDT)
Cc: rgrimes@gndrsh.aac.dev.com, hackers@freebsd.org
In-Reply-To: <11825.809900082@time.cdrom.com> from "Jordan K. Hubbard" at Aug 31, 95 01:14:42 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1407      
Sender: hackers-owner@freebsd.org
Precedence: bulk

> 
> > > > Already done!  The crunched binary is, in turn, compressed.
> > not in -current it isn't.....
> 
> Say what?  Where are you looking??
> 
> 				Jordan
> 
I made one today

look in the makefile..

release.8: write_mfs_in_kernel
        @cd ${.CURDIR} && $(MAKE) ckRELEASEDIR
        rm -rf ${RD}/mfsfd
        mkdir ${RD}/mfsfd
        cd ${RD}/mfsfd && \
                mkdir -p dev mnt stand/help
        @cd ${.CURDIR} && $(MAKE) installCRUNCH CRUNCH=boot \
                DIR=${RD}/mfsfd/stand ZIP=false

                                      ^^^^^^^^^

as opposed to the fixit..
release.10: 
        @cd ${.CURDIR} && $(MAKE) ckRELEASEDIR
        rm -rf ${RD}/fixitfd
        mkdir ${RD}/fixitfd
        cd ${RD}/fixitfd && \
                mkdir stand bin sbin etc mnt mnt1 mnt2 mnt3 mnt4 tmp    
        ln -f ${RD}/kernels/GENERIC.kz ${RD}/fixitfd/kernel
        @cd ${.CURDIR} && $(MAKE) installCRUNCH CRUNCH=fixit \
                DIR=${RD}/fixitfd/stand ZIP=true

this would give us a 'little' more room.. at the moment, the
limit is thte fact that the current GENERIC +FS
DEcompresses to > 2MB
but if we gzip the crunch file
the decompressed size would shrink, but the compressed
file would remain about the same..
and running gzipped executables can't share text segs,
so we MIGHT run short or ram at run-time..
need to check it I guess.
(but we'd gain 400k back as well)


julian