Subject: Re: resource allocation, pcmcia, isapnp, etc.
To: Jordan K. Hubbard <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/17/1999 07:34:26
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
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.