I'd like to limit this discussion to technical issue.
So, please change the subject if you'd like to discuss non-technical
issue.

> 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).

Yes. I know.
But I object that the new-bus is much cleaner than config.new.
Acutually new-bus's DRIVER_MODULE() is worst way to represent
meta information. The way of config.new(8) and it's dynamic
configuration is far more generial, and cleaner.

> 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.

About "at anytime a device may enter or leave the device instance tree",
this is already done in NetBSD's config.new system. Please look at
SCBUSIOSCAN on scsibus for attaching, and sys/dev/ic/com.c:com_detach()
for detaching.

About "at anytime a device driver may enter or leave the driver tree",
this is one of major target of newconfig project, and it is apparent
that it can be done.

Thus, in summary, there is no reason to reinvent wheel.

> 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).

In this area, current new-bus stuff is still far worse than NetBSD's.
FreeBSD's current bus_dma interface has a major flaw about dynamic
configuration. (NetBSD's bus_dma interface doesn't have this problem.)

> 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).

DEVMETHOD() is worst way to achieve compatible device drivers.
Any other operating systems which allow dynamic loading device driver
has such feature? No, there isn't. It is not needed. It is slow.

How many times does the bus_if.m is changed?
The answer is "many". And it always breaks binary compatibility.

DEVMETHOD() doesn't provide anything.
It is simply not needed.

> : 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.

New-bus has a flaw about this.
There is no way to tell a dynamic loaded frontend driver about whether 
it's backend part is statically linked or not.

In summary, config.new based dynamic configuration is better than
new-bus, IMHO.
--
soda