Date: Wed, 12 May 1999 15:29:52 -0700 From: Mike Smith <mike@smith.net.au> To: Noriyuki Soda <soda@sra.co.jp> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Tomoaki NISHIYAMA <tomoaki@biol.s.u-tokyo.ac.jp>, rwhitesel@nbase-xyplex.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <199905122229.PAA01663@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 13 May 1999 01:32:56 %2B0900." <199905121632.BAA23027@srapc342.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Why should we, as a 3rd millenium OS need a static config tool ? > > For example, > > - To specify the drivers which is linked statically to kernel. > As I said earlier, you cannot link console driver dynamically, > If you do this, you cannot get error message when dynamic > linking of the console driver failed. This presumes you don't have a fallback console driver. If you look at the current console driver architecture, you'll see that it's not too difficult to do this, nor would it be too difficult to componentise the various console driver components and simply link-time aggregate them. > - There should be a way to inform kernel about inter module dependency > dynamically. config(8) converts this information to a file which is > kernel readable format. This is _the_ fundamental defect (as opposed to merely shortcoming) with newconfig. If I want to use a vendor-supplied driver module, I must first generate a kernel that knows about it. This is not "dynamic" by any definition of the word. KLD should (but does not, yet) obtain this information from the module as it is loaded. This is not a flaw in the KLD design, only its implementation. > - There should be a way to inform kernel about mapping from device > name to driver filename dynamically. config(8) converts this > information to a file which is kernel readable format. This is a task for a PnP ID:module mapping database. See eg. sys/boot/common/pnpdata. It should most definitely _not_ be inside the kernel. > - To achieve better performance in both UP and SMP cases. > Proper SMP implementation requires fine grained locking, though this > increases performance penalty in UP case. (e.g. Solaris shows this > problem.) Thus, the way to specify "options SMP" is needed to use > (static) source level and compiler level optimization. > This option should automatically select the appropriate sources > which is compiled into kernel, according to the source is needed > only in UP case, or only in SMP case, or both. This is what > oldconfig and newconfig does. This is, again, defective reasoning. For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199905122229.PAA01663>