In message <199906171434.HAA20417@Pescadero.DSG.Stanford.EDU> Jonathan Stone writes:
: I've heard some brief comments, in passing, about more dynamic
: (boot-time) configuration, better support for dynamically-generated
: /dev entries, usw. But as best I can tell, those're orthogonal to what
: NetBSD gets from config.new.

There are many facets of new-bus.  I'll try to summarize them here.
First, it is designed to replace the config system (be it the POS
config that FreeBSD is using, or the much clearner config.new that
NetBSD, OpenBSD and BSDi are using).  One major thing that it does
allow is that at anytime a device may enter or leave the device
instance tree, and at anytime a device driver may enter or leave the
driver tree.

Another facet of new-bus is its integreation with the resource manager 
and the bus space/bus DMA code.  This allows devices to request the
"default" resources for the deivce.  The bus driver allocates them and 
creates bus space and bus tag entries that the device uses.  This
allows devices to be written without the need to have bus specific
versions of the just to get the bus space/bus tags right.  Also, since 
the allocation requests are passed up the tree, bridges can listen in
on those requests and cause the proper mappings to happen
automatically (eg the pcic chip, which provides a pccard attachment
for pc cards, knows when the a device requests a memory window or an
I/O window and cause it to be mapped).

There are other facets as well.  The biggest one is a generic "method" 
mechamism where two parts of the system can defince an interface that
allows for function call pointers and augmentations of the interface
over time in a binary friendly way.  This is a generalization of the
various chip function tables that NetBSD has (cf the pccard
subsystem).

: To me, the most important thing about new-config is the split between
: per-bus/per-card device frontend drivers, and how they attach to an
: I/O-bus topology; and the back-end chipset drivers.  That lets us
: handle boards based on M chipsets on N differnet busses with N+M bits
: of code, rather than NxM. As FreeBSD moves to more architectures
: that'll be increasingly important for you guys.

We understand this.  newbus specifically allows for this, as well as
for "generic" attachment when no bus specific code is needed.  Many of 
the drivers don't always live up to this idea in FreeBSD's code (I'm
thinking specifically of the sio and ata drivers which know a little
too much about how they are attached at too many places).  It is very
important to be able to do this.  There are several MIPS chips that
I'd like to targt FreeBSD to that have 16550 clones built into chip
and memory mapped at a specific address.  After a few tweaks to the
sio driver, I should be able to attach to those devices and use them
w/o even needing a bus specific front end.

: I think it'd help longterm collaboration between both groups (e.g.,
: the USB code) if you could explain what FreeBSD is doing with its
: `new-bus' architecture, where you see an overlap between that and
: new-style autoconfig, and where Torek-style new-config causes problems
: for more dynamic configuration.  Cause we're interested in that, too;
: and the more we can share the more everybody wins.

Definately.  We should get Doug Rabson involved in the discussion as
well, since I'm only giving a very brief flavor of what new-bus gives
(or is planned to give).

: Past discussions about similar issues with bus-space and bus-dma have
: been a win for everyone; I think thats true here too.

Definitely.  bus-space and bus-dma were excellent ideas that have been 
merged into FreeBSD.  FreeBSD could be better about tracking interface 
changes to bus-space and bus-dma, however.

Finally, I've only given a small flavor of new-bus and its future
directions here.

Warner