>In newconfig, the information is represented by "files*" file,
>thus it can be used by both static configuration and dynamic configuration.


I've been muttering about dynamically rerunning torek-style
autoconfiguration (from a given node in the autoconfig tree) for
years.  I'm told NetBSD finally has everything in place to start doing
that, if the reconfig is done within a kernel thread, so it can block.

I'd also kicked around ways to dynamically add new-config tuples to
the in-kernel database.  Its easy to reserve some `spare' entries and
add hooks to `register' a new entry; the hard part is constructing
them properly and getting the ordering right.  To date I'd assumed a
userland process with the same smarts as config.new, which fed the
tuples in as an ancillary part of the `load an LKM' operation.

I wasn't at Usenix, so I dont know how much of this the FreeBSD-plus
config.new people have (re)implemented. Is there an online copy of a
paper/talk/slides/code anywhere?

>Your requirement is already implemented in com_pcmcia driver of
>NetBSD-1.4. Config.new doesn't have problem about this.
>The reason why it is not implemented in network interface is that
>current implementation of ifnet structure doesn't support this.
>I.e. it is not problem of configuration framework, but problem of
>network stack. And the problem will be fixed by kenh's if_detach
>branch.

The real problem was inadequate refcounting of struct netifs and other
structures from within the networking stack. This is being fixed.  And
in this context its a non-issue: details of device *de*tachment is
orthogonal to how devices are configured and attached.

>If you have enough knowledge about config.new, you should already
>have known that config.new doesn't have this problem.
>Because first implementation of config_detach() has been known since
>1996. (far before new-bus is started)

I think the strongest technical criticism is that FreeBSD's interface
is _gratuitiously_ incompatible.  BSDI, NetBSD and OpenBSD all use it.
FreeBSD uses bus-space and bus-dma (closely related variants, anyway).
Given the desire on all sides for more compatiblity, an apparently
gratuitous incompatiblity seems a legitimate, technical criticism.

The (very few) discussions about this I've had with FreeBSD people
left me with a very clear impression that they hadnt used config.new,
didnt really understand it, or how it had evolved since 4.4BSD, and
simply werent interested in whether the `new-bus' goals could be
realized within a config.new framework.

Warner: Like Soda, I dont understand. The things you list as problems
with config.new were well understood in 95-96 timeframe. Did you guys
not look at them, or what?