Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 1997 19:57:21 +1100 (EST)
From:      Julian Assange <proff@iq.org>
To:        jkh@time.cdrom.com (Jordan K. Hubbard)
Cc:        hackers@freebsd.org
Subject:   kernel configuration
Message-ID:  <199701220857.TAA08248@profane.iq.org>
In-Reply-To: <28199.853858730@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 21, 97 06:58:50 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> > Have you considered adapting the current visual kernel
> > options code to manage compile time options as well?
> > It seems to me that this would provide a very nice
> > unified interface. Brief descriptions of the device
> > could be displayed in an additional horizontal region,
> > perhaps augmented with a computer readable flag mask
> > description language.
> 
> Yes, we've definitely considered it.  Unfortunately, there's
> no framework for it and the compile-time options also do more
> than just set variables which sysinstall might be able to tweak
> afterwards, they selectively compile sections of code and how do
> you conditionalize THAT after the fact? :-)

Well, you don't need to, after the fact, because if the code
ain't there - it ain't there ;)

> Maybe someday, but it's going to take some major work
> on the whole configuration paradigm.

Speaking of which, I wonder if it is time the kernel dependency
system was rationalised. I rationalised the linux equivalent (which
was (is?) a real shocker) by writing code to find every configuration
macro, and separate them out into individual .h files included by
the code that referred to it. This is similar to the current
opt_foo.h scheme FreeBSD has now. I feel a little woosey looking
at -DFFS -DIPDIVERT -DINSERTYOURUNDEPENDABLECPPDEFILEHERE's marching
up my screen during a kernel compile.  A define which does nothing
is pointless and a define which does something potentially changes
code and so must be referred to as dependency by the code it effects.
The only command line define that is acceptable is -DKERNEL.

On a slight tangential, has thought been given to clustering kernel
text/bss initialisation code at the start or end of the image
and lopping it all off once the last piece of init code is called?

Cheers,
Julian.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701220857.TAA08248>