Re: fastest UltraSPARC hardware NetBSD runs on?

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Tue, 28 Oct 2008 11:07:43 -0400
Michael <macallan%netbsd.org@localhost> wrote:

> Umm, there's prior art for this in the kernel which does not require  
> rototilling all i2c drivers. See sys/arch/macppc/dev/ki2c.c and  
> ki2c_dbcool.c.
> It does just what you try to do - attach i2c devices using
> information from OpenFirmware.
I saw this and found it to be a bad idea. It is unable to attach any
existing i2c device. Instead it introduces a new "bus": ki2c. This way
any i2c device, that wants to attach to ki2c, needs a special MD ki2c
attachment stub. Thus existing i2c drivers would need to be split up in
a MI backend and a MD / bus dependent frontend. If this isn't
rototilling, what else is rototilling? Or, even worse, copy the MI i2c
device driver to a MD version and adapt the copy to the MD bus...

So instead fixing the direct configuration problem once and forever and
in an MI way for all ports, I would add a clone of the ki2c stuff to
sparc64. Every other port, that supports a directly configured i2c,
would need to add similar code like the ki2c stuff: i.e. code
duplication. Code duplication is not a good thing. If code duplication
happens it is a sign of bad design.

I would much more prefere the "new way" and convert macppc to use it.
Also think about i2c devices on e.g. i386 where i2c may be argumented
by ACPI. (But I have no clue about i386 and ACPI.)

Note that this "new way" is not my invention. I ported it from OpenBSD
along with the device drivers. OpenBSD also has a scan function that is
able to scan an i2c bus for knowen devices where no direct configuration
is available. But this bus scan can be dangerous and is unreliable.
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/