Date: Thu, 13 May 1999 06:05:34 +0900 (JST) From: Noriyuki Soda <soda@sra.co.jp> To: Julian Elischer <julian@whistle.com> Cc: Noriyuki Soda <soda@sra.co.jp>, Rick Whitesel <rwhitesel@nbase-xyplex.com>, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <199905122105.GAA00338@srapc342.sra.co.jp> In-Reply-To: <Pine.BSF.3.95.990512115914.22596C-100000@current1.whistle.com> References: <199905121341.WAA22134@srapc342.sra.co.jp> <Pine.BSF.3.95.990512115914.22596C-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Wed, 12 May 1999 12:12:54 -0700 (PDT), Julian Elischer <julian@whistle.com> said: > 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). This is also aim of newconfig, although console driver should be linked statically at least. Also, newconfig is aiming to provide freedom to choose whether a driver is linked dynamically or statically. > 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. Yes. This is what newconfig on dynamic configuration does. But SYSINIT() of drivers is NOP in newconfig. Configuration framework does know all necessary operation to do, thus, there is nothing to do in SYSINIT(). Note that this is one of the key points to achieve best match policy for driver selection. > 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. These modules should be specified by device name, or by feature name (i.e. attributes), oldconfig and newconfig use this model. But new-bus doesn't. It doesn't use device name and doesn't have the feature like the attributes of old/newconfig. It merely uses modules' filenames to specify modules which should be linked. This is one of the points what I think the new-bus is wrong. All configuration information should be specified by specification (device names and attribute names), not implementation (module filename). This is critical point to achieve on-demand dynamic loading and better compatibility. > 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. IMHO, that's wrong. What newconfig produces is only what really needed. If you think there is unnecessary information, probably it means that you don't really understand the usage of the information, yet. > This infrastucture would be duplicated by a dynamic loading framework. This is wrong. The newconfig uses same information and same framework on both static and dynamic configuration. There is no duplication. > why have two such frameworks? No. The newconfig is unified framework for both static and dynamic configuration. If a driver is static configurated, it's "struct cfdata" is generated by config(8), and it will be parsed by configuration framework (kern/subr_autconf.c). If a driver is dynamically configured, then kernel generated "struct cfdata" is used instead. Thus, there is no duplicated information between static and dynamic configuration in newconfig. Both configurations use same "struct cfdata". The only difference is whether the generator of "struct cfdata" is config(8) or kernel. Do you call this duplication? Then you might not really understand what the configuration is, yet. Only config(8) reads "files" file (i.e. meta information) and it converts the information to binary format for kernel. So, there is no duplication about meta information parser. Yes, there is duplication about parser of configuration hint. But if you imagined that there is no need to implement the parser of configuration hint on userland. Then that's completely wrong. If config(8) doesn't have the parser of configuration hint, then you cannot determine which modules should be linked statically. The reason why new-bus doesn't have this duplication is new-bus doesn't have static configuration ability and it depends on oldconfig about static configuration. Actually, the one which has two framework is not newconfig, but new-bus. New-bus have it's own configuration framework for dynamic configuration and depends on oldconfig framework for static configuration. These frameworks are completely different, and as soon as you'd like to remove oldconfig, real problem of new-bus appears. As I said earlier, eventually new-bus will have to choose one of the following ways: [a] gives up static configuration. [b] uses ugly kluge (e.g. oldconfig remains forever). [c] reinvents features which already implemented on the newconfig. I'm not sure which is the way of the new-bus, in this point, though. > 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. This is completely misunderstanding. The "struct cfdata" can be generated via both static and dynamic way. There is no "static device framework" in newconfig from the first since 4.4BSD. Note that the structure of the parent vector and locator vector are changed from NetBSD's format. But this is well known problem (cgd already mentioned this several years ago), and doesn't affect any device drivers. Only configuration engine (kern/subr_autoconf.c) should be slightly modified. And it is quite trivial. This is what 4.4BSD red daemon book said that "all well understood and easy to fix". Do you deny this description of the daemon book ? -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905122105.GAA00338>