> [[ I will continue to discuss this as long as it seems relevant to
> this mailing list.  If people feel that its relevance is waning,
> please let me know and we can move the conversation to private mail or 
> another list. -- imp ]]

I agree with this. Please let me know if people think this is not
appropriate for this list.

> I'm curious why you find DRIVER_MODULE worse than config.new's meta
> information storage.  Can you give examples of both?  I don't
> understand what you are objecting to here.  Can you provide more
> details?

As far as you will support static configuration, the information
represented by DRIVER_MODULE() is also needed for static
configuration. But because DRIVER_MODULE() is embeded in C source, the
information cannot be used by static configuration.
In newconfig, the information is represented by "files*" file,
thus it can be used by both static configuration and dynamic configuration.

> : 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.
> 
> In the old pccard code for netbsd, if you were to insert and remove
> the same card multiple times (an ethernet card, for instance), you'd
> wind up with many instances of that device (eg ed0, ed1, ed2, etc).
> Is that still the case with the newconfig project?  I'm finding it
> hard to comment on directly because my experience with config.new have
> been limited.

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.

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)

> : 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.
> 
> I find it hard to comment on this point because I'm not sure how
> config.new handles these things.  May I ask for more details on how it 
> is done, or how you plan to do it?  I'm afraid that I need more
> details here in order to be able to effectively comment.

Just like new-bus does. Our plan includes dynamic loading bus code
and other features of new-bus.
We will make binary format of "files" file, and make it readable by
kernel at any time when it is needed.
This supports on-demand loading of device drivers which cannot be
implemented by new-bus.

> : 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.)
> 
> While bus_dma isn't part of new-bus, but there are dependencies there.
> I'm not sure that I understand the issue that you are talking about
> here.  Can you provide more detail on how FreeBSD's interface bus (or
> in this case the bus_dma interface) is flawed for dynamic
> configuration?  I've not run into these problems yet and am interested
> in correcting them.

It is problem of FreeBSD's callback interface of bus_dma(9) and it's
usage. It can be fixed by changing it's usage, but I think NetBSD's
interface is better than fixing usage.

> : 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.
> 
> I think that we disagree on this, except for the slight performance
> penalty (which I agree is present, but likely not a significant source
> of slowdown).  The DEVMETHOD stuff insultates changes to the interface
> (specifically additions) from the drivers.

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

What does DEVMETHOD() provides ?
Does it permit deletion of function interface?
No, Defined function interface cannot be deleted.
Does it permit a change of struct definition ?
No, It doesn't support a change of struct.
What does DEVMETHOD() provides ?

DEVMETHOD() adds unneeded perfomance penalty without any reasonable
feature.

> : How many times does the bus_if.m is changed?
> : The answer is "many". And it always breaks binary compatibility.
> 
> I disagree that it always breaks binary compatibility.  If the change
> is to add a new method, then binary compatibility is retained.

This can be done by simple function vector.
DEVMETHOD() is not needed.

> Changing the parameters of an existing method can break
> compatibility[*], as will deleting methods.

In other words, DEVMETHODS() adds no meaningful feature.

> If one wanted to add a parameter to foo, a new function (say
> foo_20) can be added with the "default implementation" being to call
> foo() without the parameters.  More work could be put into the method
> generator to allow for effective versioning.  It is not there today.

This can be done easily without DEVMETHOD().

> bus_if.m is still evolving and the interface to it hasn't been
> finalized yet.

In other words, bus_if.m increase possibility of a incompatible change.

> : There is no way to tell a dynamic loaded frontend driver about whether 
> : it's backend part is statically linked or not.
> 
> I'm not sure I understand this complaint.  If I were to add a pcmcia
> frontend to, say, the aic driver, which I have statically linked into
> my kernel.  When I load aic_pccard.ko, it will resolve the symbols in
> the kernel that the aic frontend uses.  There is a minor flaw in the
> kld structure right now where it will always load all modules that a
> module depends on when it loads that module.  I will grant that is a
> flaw in FreeBSD, but it is not part of new-bus. 

That's wrong.
In dynamic configuration of config.new, bus independent part of aic
driver can be linked statically or dynamically. And bus dependent part
doesn't have to know about whether bus independent part is statically
linked or not.
New-bus lacks this feature, new-bus doesn't have ability to describe
whether bus independent part is linked statically or dynamically.

> At present this bug precludes having a single dynamic frontend that
> can work with both the dynamicly loaded backend and a statically
> linked backend, optimally.

This is one of bugs of new-bus design.

> The consequence of this bug is that the backend driver will be
> loaded and there will be two copies of the backend driver in kernel.

Newconfig supports this in it's design.

> One could not place the dependency in the aic_pccard.ko file. 

This is worse than the newconfig way.

For example, if you will change the name of the backend driver, or
if you will split backend driver into two part, aic_pccard.ko will 
no longer work.
Newconfig doesn't have this problem.

> This would allow you to use the same file for both static and
> dynamic cases outlined above.  It would force the user to loadthe
> aic_backend.ko module before loading aic_pccard.ko module if the
> user hadn't compiled in the aic driver statically.

How does KLD know that aic backend is already statically linked?
New-bus doesn't have infrastructure about this.

> While this is a problem, I would argue that this is an edge case
> that few people would run into.

Edge case? No, This is so common for properly separated frontend
and backend. Why doesn't new-bus people ever think about this?

> This is also a flaw that can be corrected and is not inherent in the
> new-bus architecture.

Where is infrastructure which describe which module is linked
statically in the new-bus?

Config.new already provides the "attribute" about this.
What we will do is to make this information available dynamically.

New-bus currently provides nothing about this.

> One problem that I've seen in all the instances of this discussion is
> a lack of clear documentation for both new-bus and config.new (as
> modified by the FreeBSD newconfig project).  I'm not sure how to
> rectify this problem.

I don't think so.
Config.new(8) is available for many years. And red daemon book
explicitly said that
	after the system is completely booted, 4.4BSD
	(i.e. config.new) cannot load device drivers....
	These problems are all well understood and 
	EASY TO FIX.
in it's page 502.
(and red daemon books is published before new-bus is started)

If you think about how you can implement this with config.new,
the answer is there. There is no reason to reinvent wheel like new-bus.

> At this time, I don't think my Japanese would be up to the task of
> having a detailed, technical conversation.

All japanese people are admiring you for your effort to learn Japanese.
--
soda