Date: Wed, 17 Dec 1997 06:26:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: j_mini@efn.org Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <199712170626.XAA12538@usr09.primenet.com> In-Reply-To: <19971216174321.03686@micron.mini.net> from "Jonathan Mini" at Dec 16, 97 05:43:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Please understand that I am attacking this as two seperate systems :
>
> 1) A system which manages building of multiple options or modules into
> one or more modules which together make a "kernel." (this means support
> for both a static kernel and a completely dynamic kernel. Both extremes
> will be useful to different people, but the majority of us will want
> something in the middle)
This is useful, but I would claim it's a second system problem, ie: it's
not something you want to solve in an initial revision. Since it's
logically seperate, you won't architect it into impossibility no matter
what your approach on the other problem.
> 2) Another system which manages that management. This is the "kernel
> configuratior" and one will be neccisary to build static kernels, no
> matter how you look at the problem. While I am all for dynamic kernels,
> a static kernel is still very useful, and I VERY much do not want to
> see that possibility go away.
The static kernel is, I think, an ld option to the Makefile for the
kernel, probably set in /etc/make.conf.
The ld option dictates what sections you choose to link, and is
referenced via /usr/share/bsd.kern.mk.
As a rough example (this is not verbatim, no syntactic attacks, please),
boot-critical devices would have:
#pragma section('text',SECT_TEXT_BOOT_CRITICAL)
#pragma section('data',SECT_DATA_BOOT_CRITICAL)
At the top.
For dynamically loadable devices, you would have:
#pragma section('text',SECT_TEXT_DYNAMIC)
#pragma section('data',SECT_DATA_DYNAMIC)
One option would tell ld to link both *_BOOT_CRITICAL and *_DYNAMIC
ELF sections into the kernel file.
The other setting would tell ld to link only *_BOOT_CRITICAL ELF
sections into the kernel file, and to place objects with *_DYNAMIC
sections into /libexec/drivers (or wherever dynamic driver files
go so the kernel can find them).
Neither of these options require a configurator, only a programmer. 8-).
> It should also be noted that this tool will be needed to configure
> compile-time options of the modules.
Compile time options should go away. Period. All of them. They
are bogus.
Runtime options are manipulable by causing the registration of sets
of symbol/type/default_value/validation_function into a MIB. sysctl
is a MIB manager. LDAP is a MIB manager. SNMP is a MIB manager.
Management of the values is via MIB manager. Values are persistent
unless their type dictates otherwise, and you can always get ther
default back later, if necessary.
> Currently, I haven't even begun to think about part 2, but am instead trying
> to come up with an easy-to-maintain and extendable method of implementing part
> 1. I am to replace the config(8) utility and it's underlying build method with
> something that will remove many of the problems of config(8).
Or... you could remove all of the problems by removing config in
its entirety instead of providing a replacement. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712170626.XAA12538>