DragonFly kernel List (threaded) for 2004-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: New debug kernel installation mechanism committed to HEAD
:Note that the group "they" includes some people who understand
:exactly what you were suggesting, and what the goal is...
:
:--
:Garance Alistair Drosehn = gad@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@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]