New debug kernel installation mechanism committed to HEAD

Matthew Dillon dillon at apollo.backplane.com
Thu Oct 21 00:26:32 PDT 2004


:Note that the group "they" includes some people who understand
:exactly what you were suggesting, and what the goal is...
:
:-- 
:Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx
    
    True.  But it gets lost in all the other postings.  It is a prime example
    of how compromises and me-to's lead to a solution that winds up being
    the diametric opposite of the purpose behind the original suggestion.
    I'm especially disappointed in some of the comments made by experienced
    developers who seem to be complaining about it bloating their totally
    custom configs, as though they couldn't be bothered to add a simple
    directive to those particular configs, and others who seem to be
    advocating a ridiculously complex separation or a separate-copy solution
    just to save 10MB in / for people building DEBUG kernels.  It makes no
    sense whatsoever to me.  Those are the people who ought to be setting
    a better example.

    We'll see if anything reasonable ever actually goes into the FreeBSD
    tree.  I would be pleasantly surprised if it did.

    In anycase, its in the DFly tree now so you can pick the patch set
    out of the commit message.  It was really easy.  The only major
    difference between DFly and FreeBSD vis-a-vie the kernel build is that
    we have two targets: buildkernel and nativekernel, where buildkernel
    strictly uses utilities built by buildworld and nativekernel just uses
    system utilities.  This required some cleaning up of the build 
    environment for the installkernel stage since that stage now uses
    objcopy to do the debug strip, and objcopy is objformat 
    (aka OBJFORMAT_PATH) based.  But everything else is applicable to
    FreeBSD, I think.

    One interesting facet of this work is that it was noticed that when DEBUG
    is used, DragonFly already installed fully debug-symboled modules into
    /modules, which equates to +30MB and then another +30MB when 
    installkernel makes the modules.old backup.  I decided to leave the
    default as is... that is, install the debug-symboled modules, but the
    backup copy is now unconditionally stripped (saving 30MB) and an option
    exists to strip the primary modules as well, independant of the kernel.
    So DFly users who build DEBUG kernels actually get a 20MB savings by
    default and a 50MB savings if they use the option to strip the modules
    on install, even though they are now installing a full debug kernel in
    /.  And this was happening to the snapshot and release CDs too, so we
    wind up saving 20MB on the CD (-30MB modules, +10MB kernel).  

    That is humerous to say the least.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list