Date: Tue, 16 Dec 1997 17:43:21 -0800 From: Jonathan Mini <j_mini@efn.org> To: Terry Lambert <tlambert@primenet.com> Cc: daniel_sobral@voga.com.br, hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <19971216174321.03686@micron.mini.net> In-Reply-To: <199712161847.LAA18094@usr01.primenet.com>; from Terry Lambert on Tue, Dec 16, 1997 at 06:47:57PM %2B0000 References: <8325656F.0038C91F.00@papagaio.voga.com.br> <199712161847.LAA18094@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ .... much ramblings by many people deleted .... ] 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) 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. It should also be noted that this tool will be needed to configure compile-time options of the modules. 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). -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971216174321.03686>