[[ 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 have a few areas that I've been unclear on for this whole
discussion, so I'm going to ask you to clarify a few points.  I find
that I'm having trouble commenting on a few points, so please bear
with me.  Other points I will try to answer the best way I can.  This
has been a contentious issue in the past.  My hope is that it won't be 
in this go around.

I also want to state that I have a deep respect for the people who
have crated the FreeBSD newconfig project.  Please do not take any
critism for parts of newconfig as a personal attack.  If it sounds
like I am attacking personally, please let me know.  I have no
intention of doing that.

In message <199906181028.TAA13383@srapc342.sra.co.jp> Noriyuki Soda writes:
: But I object that the new-bus is much cleaner than config.new.
: Acutually new-bus's DRIVER_MODULE() is worst way to represent
: meta information. The way of config.new(8) and it's dynamic
: configuration is far more generial, and cleaner.

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?

: > One major thing that it does allow is that at anytime a device may
: > enter or leave the device instance tree, and at anytime a device
: > driver may enter or leave the driver tree.
: 
: 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.

: 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.

: 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.

: > There are other facets as well.  The biggest one is a generic "method" 
: > mechamism where two parts of the system can defince an interface that
: > allows for function call pointers and augmentations of the interface
: > over time in a binary friendly way.  This is a generalization of the
: > various chip function tables that NetBSD has (cf the pccard
: > subsystem).
: 
: 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.

: 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.
Changing the parameters of an existing method can break
compatibility[*], as will deleting methods.

[*] On some architectures, you can add parameters and old functions
will just not use the new informatin in those parameters.  To the
extent that information is required, yes that would break things.  If
the information isn't required by the old interface, it will continue
to work.  Not all architectures will support this, however, so it
would no tbe fair to claim that new-bus' architecture would allow for
this.  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.

bus_if.m is still evolving and the interface to it hasn't been
finalized yet.  Judging the changes to an interface in the unreleased
(eg -current) version of FreeBSD is not necessarily indicitive of how
the releases will be handled over time.

There is a valid complanit here about the current design of new-bus.
You are correct that it doesn't provide a versioning mechanism.  With
careful editing of bus_if.m and other files after the API has been
frozen, it will not be an issue for some time to come.  With careless
editing of bus_if.m, then it can become a big, throny problem.  Which
way it will turn out is unknown at this time.

: 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.  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.
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.  

One could not place the dependency in the aic_pccard.ko file.  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.  While this is a problem, I would argue
that this is an edge case that few people would run into.  This is
also a flaw that can be corrected and is not inherent in the new-bus
architecture.

: In summary, config.new based dynamic configuration is better than
: new-bus, IMHO.

I beleive that we still differ on this point.  We may never agree on
it, but at this point I know that I still need more information.

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.

Thank you very much for your comments about new-bus.  I do appreciate
them.  I look forward to your answers.  I appreciate your efforts at
writing in English.  At this time, I don't think my Japanese would be
up to the task of having a detailed, technical conversation.

Warner