Date: Wed, 12 May 1999 12:12:54 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Noriyuki Soda <soda@sra.co.jp> Cc: Rick Whitesel <rwhitesel@nbase-xyplex.com>, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <Pine.BSF.3.95.990512115914.22596C-100000@current1.whistle.com> In-Reply-To: <199905121341.WAA22134@srapc342.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
My personal opinion is that static configuration is a subset of dynamic configuration. The eventual aim is to have a kernel which is a very sparse skelaton, with very few services and drivers loaded (in fact possibly none). At boot time, the needed drivers and services are loaded and configured (by the loader possibly). A driver that is already linked in is treated exactly as if it had been loaded, except that the loading is not required.. In this view, a statically linked in module is really just a 'pre-loaded' module. it still needs to be initialised. In this view, config(8) is reduced to being used to specify the preloaded modules (though that may be done after compilation by an external linker/loader) and to specify debugging options. A utility could exist that takes a skelaton kernel, and a specified list of kld modules and creates a composite loadable kernel, in which some modules are already present. I will admit that I have only looked a small amount at the new config that NetBSD uses, but it seemed to me that it produced far too much static information. This infrastucture would be duplicated by a dynamic loading framework. why have two such frameworks? If newconfig has removed all static device framework from the kernel then it is going the way I envision things moving. If it still does what the NetBSD one did when I looked at it, and produces a statically compiled framework of child devices and parent nodes, then that is one of the things we are trying to get away from. julian On Wed, 12 May 1999, Noriyuki Soda wrote: > >>>>> On Wed, 12 May 1999 09:35:36 -0400, > "Rick Whitesel" <rwhitesel@nbase-xyplex.com> said: > > > In general I believe that dynamic configuration of the system is > > extremely useful to both the development community and the user > > community. The development community has a much easier time if they > > can load / unload drivers. As for the users, my rule of thumb is > > that a computer should never ask a human the answer to a question > > that it can find out for itself. I think this is especially true for > > configuration information. In addition, the need for dynamic system > > (re)configuration will only increase as features like PCI hot swap > > become the standard. > > Of course, I completely agree with you. > > The reason I prefer newconfig is it actually can support dynamic > configuration better than the new-bus. All features which new-bus has > can be implemented on newconfig, too. And, more. (See the description > about on-demand dynamic loading in my previous post.) > > Furthremore, newconfig does static configuration better than the > new-bus, and newconfig has a option which removes dynamic configuration > entirely from kernel. New-bus apparently doesn't have this option. > > So, which is flexible ? :-) > -- > soda@sra.co.jp Software Research Associates, Inc., Japan > (Noriyuki Soda) Advanced Technology Group. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990512115914.22596C-100000>