Re: Linux Incompatibility List

Andrew Miklas
2004-08-29T01:43:10Z

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Hi,

On August 25, 2004 03:21 am, Gianni Tedesco wrote:
<snip>
> Also I think that the pciproxy[0] technique currently offers a simpler
> solution. Analyzing the data produced is more akin to reverse
> engineering a network protocol than machine code. Reverse engineering
> protocols is much less 'copyright sensitive' than decompiling machine
> code and, I think, more easily shared.

(Sorry for the long delay...)

Yeah, we tried that at first too (actually, we were using Frank Cornelis'
patches to Bochs). The problem with dumping all the PCI activity (even while
the interface isn't sending/receiving) is that there is a huge amount of data
to sift through. Even capturing for just a for a few seconds generates
megabytes of data. You also have to deal with various events (like the
watchdog timer) going off at random times and getting mixed in with the
send/receive data. We also found DMA a little tricky too (ie. you need to
dump out any data that the chip will bus-master to itself to see how it is
structured).

Also, we figured it would cause problems for supporting the whole range of
devices that can be handled by the wl.o drivers. For example, from looking
at the module, we can see that the driver will have somewhat different
behaviour according to exactly what MAC and radio chips are present, the
interface being used (ie. PCI, cardbus, etc.), the vendor, model number, and
revision of the board itself, the contents of the ROM, etc. We decided that
there was simply too many combinations to make the data capture approach
useful over the entire range of Broadcom hardware, unless you repeat the
process on every variation.

> Anyway, perhaps once I've had some time to make a little more progress
> we would be able to compare some notes?

Sure, let me know when you're ready.

-- Andrew

[-- Attachment #2: Type: application/pgp-signature, Size: 201 bytes --]