Re: Linux Incompatibility List

[Andrew Miklas <public@mikl.as>]

[-- 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 --]