Jordan,

Could you postpone dropping this from netbsd's tech-kern for long
enough to give us a brief rundown on the `new-bus' architecture?

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.

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.

Separate frontends for distinct boards using the same chipset on a
given bus should help dynamic configuration. Look at the dp8390-based
ISA boards: with separate frontendsa for each of wd80xe/smc, 3c503,
and ne2k, we can do a better job of picking or defaulting IO and IRQ
assigmnents.


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.

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