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>