From owner-freebsd-hackers Tue Dec 16 22:38:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA15206 for hackers-outgoing; Tue, 16 Dec 1997 22:38:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14714 for ; Tue, 16 Dec 1997 22:26:17 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id XAA03667; Tue, 16 Dec 1997 23:26:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd003650; Tue Dec 16 23:26:05 1997 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id XAA12538; Tue, 16 Dec 1997 23:26:02 -0700 (MST) From: Terry Lambert Message-Id: <199712170626.XAA12538@usr09.primenet.com> Subject: Re: Why so many steps to build new kernel? To: j_mini@efn.org Date: Wed, 17 Dec 1997 06:26:02 +0000 (GMT) Cc: tlambert@primenet.com, daniel_sobral@voga.com.br, hackers@FreeBSD.ORG In-Reply-To: <19971216174321.03686@micron.mini.net> from "Jonathan Mini" at Dec 16, 97 05:43:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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.