Subject: Re: Refactoring MI devices in GENERIC and friends
To: Izumi Tsutsui <firstname.lastname@example.org>
From: Michael Lorenz <email@example.com>
Date: 09/08/2007 22:43:00
-----BEGIN PGP SIGNED MESSAGE-----
On Sep 8, 2007, at 22:30, Izumi Tsutsui wrote:
> firstname.lastname@example.org wrote:
>>> doesn't macppc have vtophys()?
>>> any driver using it won't work on sparc64.
>> In dev/pci only bktr and oboe match that (with possible conditional
>> code in de(4)).
> - many drivers lack necessary bus_dmamap_sync(9) calls,
> which are mostly no-op on i386 or macppc
> (IIRC there was a report ti(4) didn't work on sparc64)
> - some drivers are not well-tested on big endian machines
> (some VLAN code might be still problematic for example),
> or also could have LE64BE bugs on sparc64
> - sparc64 (or some other ports) has more assertions in MD backend
> and some drivers could have bugs which are not caught on i386
> - some drivers might have invalid I/O accesses which only
> work in __NO_STRICT_ALIGNMENT case
Even more reasons to have these drivers in sparc64's GENERIC.
Which reminds me - gem has OpenFirmware/OBP code to find the local MAC
address, I'll fix that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----