On Thu, 11 Jun 1998, Ted Lemon wrote:
>> Does that mean that the FreeBSD development should move forward,
>> and then when we  have reproduceable benchmarks on FreeBSD, then
>> you can choose to adopt our code, or leave it be?
>
>Why do you have to have different code?   Why not try the current code
>on for size, see how it works, and *then* propopose i386-specific
>enhancements if the need arises?
>
>It *sucks* that we're still not going to have sharable device drivers.
>Device drivers are thin on the ground in the Free BSD community.  I
>think it's worth a *lot* of effort to try to improve device driver
>sharing.  I'm not saying this with the intent of offending anybody - I
>think it's a fairly obvious truth.  An incompatible API ought to be a
>*clear* win, and it ought to be *minimally* incompatible.  Nothing
>I've heard so far suggests that this is the case.

I midly disagree.  If an API must be incompatable it should be enough
incompatable that people attempting a port between models understand what
is going on.  A midly incompatable API tempts those who dno't know better
to do things like "hmm, bus_get takes an extra argument on NetBSD, lets
drop a null (0, or some other constant) in there and see if it works.  And
in 99% of the cases it will work, but by not understanding the purpose of
that extra arguemnt they didn't fill in the right value.  

If an API is goign to be similear it is worth the effort to go all the
way.  Even if that means FreeBSD needs to impliment an extra argument,
that they normally ignored.  

I'm just wondering now if it is possibal to "force" driver devolpers to
support a platform they do not have.  (ie if a bug only shows up in
NetBSD require teh FreeBSD devolper fix that code) If anyone can come up
with a way to do that without driving away good devolpers, be my guest.
It is byond me to come up with such a thing.