Messages in this thread | | | From | Andrew Miklas <> | Subject | Re: Linux Incompatibility List | Date | Sat, 28 Aug 2004 21:42:43 -0400 |
| |
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 [unhandled content-type:application/pgp-signature] | |