Date: Fri, 16 Apr 1999 10:18:46 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: UCHIYAMA Yasushi <uch@nop.or.jp> Cc: peter@netplex.com.au, rwhitesel@nbase-xyplex.com, current@FreeBSD.ORG Subject: Re: newconfig/new-bus Message-ID: <Pine.BSF.4.05.9904161016060.51054-100000@herring.nlsystems.com> In-Reply-To: <19990416171739K.uch@nop.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Apr 1999, UCHIYAMA Yasushi wrote: > | shouldn't be too hard though, but even then there are seriously non-trivial > | differences in the tty, block/character devices, VM, networking, etc. Even > | if the config interface was compatable it wouldn't ever be a 'drop in' > | option, even with 'newconfig'. > > In strongly system-dependent part, even if newconfig, it is required > many source change. But *BSD difference is smaller than other OSes. > Except for static configuration and module dependency resolvation, I > feel new-bus and newconfig have the same possibility. So new-bus seems > to `re-invent the wheel'. Why not improve 4.4BSD newconfig? Except > for FreeBSD, almost all the drivers are newconfig. (FreeBSD's > oldconfig should die) What is merit of new-bus? Identity? > > current newconfig code don't support dynamic configuration. but this > is not newconfig potential. Furuta and I intend to code it. I'm going to re-post a reply I made to Warner Losh a while ago on the new-bus-arch list. It covers most of the reasons I have for preferring new-bus from newconfig. On Sat, 10 Apr 1999, Warner Losh wrote: > > How is New Bus different than new config that NetBSD, OpenBSD, et al > have? The Japanese hackers seem to like it and have built some things > on top of its structures. The main difference in style is that we don't rely on config(8) to build a tree of possible device attachments when the kernel is configured. The drivers in new-bus are dynamically registered with all appropriate attachment points as the driver is initialised. Since this happens via SYSINIT, drivers can be trivially loaded after the kernel has booted. A simple mechanism allows un-matched devices to be automatically probed and attached when a suitable driver is loaded. My only use of config(8) at the moment is to build the kernel makefile (which includes all statically linked drivers) and to build a list of 'probe hints' for non-pnp busses such as ISA. I would like to move the probe hints into a file which can be loaded by the bootstrap at some point. Ideally, it should be possible to build a kernel with no drivers at all and have the bootstrap load all necessary modules along with the kernel. It might be hard to make console devices loadable in this way but most other drivers wouldn't even notice the difference. The next thing which new-bus gives us over newconfig is flexibility. Because all driver functions are specified in interfaces (cf. device_if.m) instead of using structures full of function pointers, new functions can be added to interfaces and new interfaces for specific busses or classes of device can be added without having to change kernel data structures or add new ad-hoc function pointer tables. To further improve the stability and longevity of separately compiled drivers (where source might not be available), all the device data structures are opaque to the driver implementor and therefore structure and/or implementation changes do not require that all drivers are rebuilt. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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.4.05.9904161016060.51054-100000>