I've been out of touch for the last couple of days, so am catching up
with a big post.  I've tried to keep who said what straight, but if I
messed up, please forgive me.  I've also tried to keep this short as
well, assuming that some points Justin will answer :-).

gibbs>	Justin Gibbs
soda>	Niroyuki Soda-san.
imp>	Warner Losh

gibbs> The information in DRIVER_MODULE() is available if you are
gibbs> statically linked or not.  It is equivalent, as I understand
gibbs> the proposed (or perhaps implemented) changes to config.new, to
gibbs> a binary version of the 'files' file.  Can you be more specific
gibbs> about why you feel this mechanism is inadequate for the
gibbs> statically linked case?  I have yet to dynamically load a
gibbs> single KLD under new-bus, but all of my device drivers still
gibbs> seem to work just fine. 8-)

Also, the information is located with the driver, rather than in a
central files* file.  This allows that informtaion to be updated
dynamically (which covers the static case).  Since the DRIVER_MODULE
information is available in the linker_set of the .ko file, you are
able to just add it to the system and the right attachments to the
driver tree are made.  When a bus scan is done (or forced), thek
kernel can use this information.

The binary representation of the files* file would also allow this,
but that is a fairly new thing.

gibbs> The thought from the new-bus camp has always been that the
gibbs> format for that data should be the same in all scenarios and be
gibbs> tightly coupled (i.e. imbedded) to the binary module.  This is
gibbs> the rational behind DRIVER_MODULE().

Yes.  If a vendor wanted to distribute a config.new driver, that
vendor would need to provide patches to the files* files.  With a
loadable module, no patches would be needed for a new-bus driver.

A current weakness in new-bus is that it still uses, to a limited
extent, old config for file grouping.

soda> DEVMETHOD() is worst way to achieve compatible device drivers.
soda> Any other operating systems which allow dynamic loading device driver
soda>  has such feature? No, there isn't. It is not needed. It is slow.
gibbs> Actually yes.  Win9X exports several interfaces using a similar method.
imp> I think that we disagree on this, except for the slight performance
imp> penalty (which I agree is present, but likely not a significant source
imp> of slowdown).  The DEVMETHOD stuff insultates changes to the interface
imp> (specifically additions) from the drivers.
soda> There is no problem about the interface additions in simple function
soda> vector without DEVMETHOD().

One other thing that DEVMETHOD gives you is the ability to have an
arbitrary number of function pointers in a function dispatch table and 
not have to worry about adding new functions (or even deleting old
ones).  This would allow one to add functions to the
pcmcia_chip_functions struct w/o worrying about breaking old binray
drivers.

: This is simply not true.  The modules do not need to know the static
: or dynamic nature of a module in new-bus either.  It is only a module
: naming issue that is easy to solve.

Yes.  It is a limitation of the kernel linker, not a limitation of
new-bus.

imp> While this is a problem, I would argue that this is an edge case
imp> that few people would run into.
soda> Edge case? No, This is so common for properly separated frontend
soda> and backend. Why doesn't new-bus people ever think about this?
gibbs> I agree, this is not an edge case, but it is already covered by
gibbs> new-bus/KLD.

I guess that I was saying having a statically linked "base" driver
(say aic) and then wanting to dynamically load either the isa or the
pcmcia front end is what is the edge case.  Most people will either
statically link in both the aic and the aic_pccard drivers, or will
dynamically load both of them.  It is an important edge case that
should be fixed in the future, but is related to the kernel linker bug 
that we talked about earlier.

In the above "static" and "dynamic" refer to the linking mechanisms
used to get the code into the kernel.  Reading other messages in this
thread shows that the other "static" vs "dynamic" issue is how the
devices are wired into the device tree, which is very different.  For
that, both new-bus and new-config handle things properly.  When you
want to add a new instance of a known driver (possibly after loading
its implementation to make it known) in the device tree, they both
cope, and cope well.

soda> For example, a static configuration like "fxp0 at isa? port
soda> 0x308 irq 5" makes a error on both newconfig and old-config,
soda> because fxp cannot be attached to isa bus. This error cannot be
soda> caught by new-bus, because the bus hierarchy information is
soda> embeded in DRIVER_MODULE() and not available on static
soda> configuration.
soda> This is one of most serious design flaws of new-bus. It is
soda> obvious that this information should not be embeded in C source.

I would argue that this doesn't happen at all in new-bus.  While the
present implementation of new-bus does use BOC (bad old config) to
handle its statical linking, I believe that two issues are relevant
here.  First, is that if there were hints for the new-bus isa bus that 
stated there would be a fxp device on that bus, they would effectively 
be ignored because the DRIVER_MODULE's registration of the driver into 
the driver tree didn't add it as a child of isa.  Second, if you were
authoring a static linking tool, and some user specified that as a
hint, then that tool could detect that, with the modules specified,
there was no way for fxp driver to attach to the isa bus.

soda> In new-bus with dynamic linking, users have to know driver's file name
soda> (to load it dynamically), and it's logical name (to specify
soda> configuration hint).
soda> In other words, new-bus uses different model of kernel configuration
soda> between static configuration and dynamic configuration.

This is true in the present state of things.  You will have to load
fxp.ko (or mondo-ethernet.ko, which has several drivers including fxp) 
to get the fxp driver.  However, the decoupling of filename from
driver name allows for colocation of drivers.

In a future without oldconfig doing the static configuration (meaning
the loading of lots of .o's into /kernel with compiled in "hints"),
one could envision where there is the core kernel (kernel) and all the
device drivers as modules (eg wd.ko, ed.ko, etc) The current static
configuration tool is /boot/loader and is a little hard to use.  It is
possible to create a minimal kernel and load in just enough devices
from the /boot/loader rc file to be able to mount / and start running
the rc scripts.

One thing that is clear, and I should mention it here, is that
newconfig can also do this loading.  Its mechanism is different but it 
can support it.

Warner