Date: Wed, 16 Dec 1998 09:54:04 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Atsushi Furuta <furuta@sra.co.jp> Cc: mike@smith.net.au, y-nakaga@nwsl.mesh.ad.jp, current@FreeBSD.ORG Subject: Re: PAO Integration? Message-ID: <Pine.BSF.4.01.9812160938320.55097-100000@herring.nlsystems.com> In-Reply-To: <199812160444.NAA07797@sramhc.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Dec 1998, Atsushi Furuta wrote: > >> In article <199812160417.UAA00907@dingo.cdrom.com>, > Mike Smith <mike@smith.net.au> writes: > > > If you haven't even looked at the issues involved in dynamic growth of > > the newconfig-generated device and bus tree, then I'd have to strongly > > suggest that you're wasting your effort right now. > > Of cource, *our* newconfig will be support dynamic growth of the > device instance tree and device directed graph. Actually, I have > changed from cfdata structure array to TAILQ. Please look at our > repository... > > > Drivers required for the boot process need to be aggregated at either > > build-time or load-time (console, root disk), and they can either be > > statically or dynamically configured - static configuration is optional > > and only required if the driver or its parend bus can't work things out > > itself. > > I have a different opinion. As noted by Doug, current implementation > of new-bus requires config(8) to specify ivars. It is not fair to say > "newconfig is static, but new-bus is dynamic" without dynamic > parameter specification. As things stand right now, the only bus which uses (needs) static configuration is the ISA bus. The existing implementation of ISA bus on the alpha platform picks up values for ivars from a simple 'resource' database constructed by config(8). Given that we can easily load arbitrary files using the new bootstrap, this information could be read from a file. I chose to use config(8) to supply the information since that would be most familiar to users of FreeBSD/i386 (and at the time, the new bootstrap wasn't anywhere near as sophisticated as it is now). The best approach for the future may be to supply all configuration data from files loaded by the bootstrap and reduce config(8) to simply constructing the build directory and building a Makefile. > > > The metainformation required to connect devices and busses is almost > > entirely contained in the drivers themselves, rather than being > > constructed at build-time by an extern configuration tool. This is > > more or less mandatory if you want to be able to add arbitrary bus and > > device code to a running system, and one of the major marks against > > newconfig. > > Our newconfig will be able to specify such a metainformation not > only at build-time, but also run-time. A key point is a counterpart > in newconfig of devclass_add_driver(9) and device_add_child(9) of > new-bus. It is not still implemented, but we eventually will > implement. (may be soon) I don't want to spend any time matching features of the two different systems (which is why I have stayed away from this thread mostly). I do think that sharing drivers between the two implementations is possible. Its certainly easy to port from newconfig to new-bus and the usb folks are maintaining a common source tree between NetBSD and FreeBSD. A far more important feature for sharing driver source code between the systems is the use of bus_space and bus_dma for accessing device hardware and this is fully supported in FreeBSD since the CAM integration effort. -- 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.01.9812160938320.55097-100000>