imp> If a vendor wanted to distribute a config.new driver, that vendor
imp> would need to provide patches to the files* files.

Soda> That's simply wrong. It doesn't need to patch the files.

Then how does it get linked into the kernel?  Why do I need to add
entries in one of the files* files before I can add a device with
NetBSD?  I'm confused.

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> That's wrong. DEVMETHOD() doesn't provide any meaningful features.
soda> All features of DEVMETHOD can be implemented without it.

No.  That's not right.  Or rather it is like saying that you can do
everything with C that you can do with C++.  You can implement virtual 
functions in C, but it is a lot easier with C++.

soda> There is no problem about the interface additions in simple function
soda> vector without DEVMETHOD().

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

soda> That's can be done quite easily without DEVMETHOD, see below:
...
soda> Note that the sc_functions member is defined as pointer to 
soda> struct. In this way, you can add/delete any number of functions
soda> without losing binary compatibility.

Ah, it isn't for binary compatibility within a driver, but binary
compatibility between the kernel and the driver.  newconfig has tables 
of function pointers that the driver provides to the rest of the
kernel.  If the kernel adds a new function, it will have no way of
knowing which drivers have this function, and which ones do not.

soda> And in reality, you cannot remove functions even with DEVMETHOD().
soda> If you do it, you have to add error checking to existing codes.

Yes.  You can remove functions with DEVMETHOD.  While references to
those functions exist in the legacy drivers, they will not be called
at all.

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.

imp> I would argue that this doesn't happen at all in new-bus.  While the
imp> present implementation of new-bus does use BOC (bad old config) to
imp> handle its statical linking, I believe that two issues are relevant
imp> here.  First, is that if there were hints for the new-bus isa bus that 
imp> stated there would be a fxp device on that bus, they would effectively 
imp> be ignored because the DRIVER_MODULE's registration of the driver into 
imp> the driver tree didn't add it as a child of isa. 

soda> That's worse. If a user misspelled the parent bus, the error will
soda> not be reported on even boot time. The user cannot understand why
soda> he failed in new-bus.

I think that this is a valid complaint.  This is a programming error,
rather than an error in config files.

imp> Second, if you were authoring a static linking tool, and some
imp> user specified that as a hint, then that tool could detect that,
imp> with the modules specified, there was no way for fxp driver to
imp> attach to the isa bus.
 
soda> How does the tool detect that? By scanning binary object?
soda> That's most insufficient and unreliable way.
soda> Newconfig's way is sufficient and reliable.

I don't believe that scanning binaries is insufficient or unreliable.
It will be very hard to provide for a binary only distribution without 
being able to do this.

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

soda> And it requires separated meta information file as newconfig does.