There is probably a best way to do this under the autoconfiguration
framework, and I don't yet know what it is.

Consider a driver foo that supplies a common layer of processing
for a lot of drivers (bar, baz, quux, and a dozen more) that it
can attach to.  It defines a struct foo_hw_if for the methods that
those parent drivers need to provide. An attribute foobus is
defined for drivers that qualify, and "foo at foobus" enables the
driver to attach to them.

It turns out that for a small number of those drivers, but only for
them, things would work much better with an additional method in
the hw_if--imagine the hw_if struct extended with one more field,
which the baz and quux drivers would initialize with the new
method, while all the other drivers initialize it to NULL.  foo uses
the new method if it is present; if it is NULL, foo continues to use
the old methods and all those other drivers work as they always did.

Now - what's the best way to make that happen incrementally, without
actually having to find all the UNaffected drivers and add a NULL to
their hw_if initializers (labor intensive and error prone)?

Is it possible to define an alternate hw_if struct, give the few
devices that use it a new attribute, say foobus2, let foo attach
at foobus or at foobus2, and detect at attach time which attribute
applies?

Right now, foo gets attached to the underlying devices in several
ways.  Some of them call its fooattach function directly; some call
its foo_attach (an implementation factor of fooattach); and some
populate an args structure and call config_found. Some have the
foobus attribute and some don't (and have dedicated config entries
like foo at metasplat). Rather inconsistent. Is there a way to make
incrementally the change I'm thinking of?

I suppose worst case I could give foo a new function
foo_register_extended_if(...) and the parent drivers that support
the new interface could call it after attachment, supplying the
additional method. I could make that work right away without having
to understand autoconfiguration better than I do, but is there a
less kludgey solution?

Thanks,
-Chap