Yes, such a Mailing List to discuss Windows driver disassembly for the purpose of porting drivers to Linux would be very very helpful. -JoJo On Sun, Apr 13, 2008 at 11:34 AM, far seer <seerfar at gmail.com> wrote: > > On Tue, Apr 8, 2008 at 9:59 PM, John W. Linville <linville at tuxdriver.com> wrote: > > On Mon, Apr 07, 2008 at 11:42:52PM -0700, Greg KH wrote: > > > On Tue, Apr 08, 2008 at 11:46:48AM +0530, JoJo jojo wrote: > > > > > > > > e) wireless is a mess because of FCC regulations, they want > > > > manufacturers to limit the operating capabilities of the > > > > device(frequencies), manufacturers figure that its cheaper to do this > > > > in s/w rather than h/w, by making a closed source firmware. I don't > > > > see how we can improve this situation unless you can help EU legislate > > > > it away (assuming US is a lost cause) > > > > > > The whole FCC thing is, in my personal opinion, a big excuse that some > > > companies are using to not release the code for their hardware. If you > > > notice, other companies do not believe this and have released code. > > > > I think it is actually some of both. Regulators (particularly the > > FCC) have failed to eliminate the spectre of threat that might come > > from opening specs and/or source code from vendors. Further, they > > continue to countenance the notion that closed-source software is > > somehow equivalent to locking-down a hardware device. This provides > > enough "cover" for vendors to "run home" to an unfriendly stance > > against open source if they have any desire to do so for whatever > > other reasons may exist (embarassment about sloppy specs, perceived > > competitive advantage, etc). > > > > > > > Either way, the very capable, and active developers of the > > > linux-wireless projects are working to resolve all of the wireless > > > driver issues. If you have questions or concerns about these types of > > > devices, please contact them. > > > > On behalf of my developers (who do all the work), I appreciate your > > vote of confidence! > > > > While I'm here, let me invite any budding reverse engineers to > > join us on linux-wireless at vger.kernel.org. As Greg mentioned the > > reverse-engineered ath5k and b43 (and b43legacy) drivers continue > > to develop, but both projects could use more help. In particular > > the b43 folks need help reverse engineering the 802.11n devices. > > > > Also, there is a project underway to reverse-engineer support for > > Airgo devices. I regret that I haven't spent much time with that > > project, but I think it is well underway. > Is the reverse engneer of Airgo device taken charge by Jeff Williams > (http://airgo.wdwconsulting.net/mymoin)? > We refer to it to developed the driver, however the driver is unstable. > Jeff said the reverse engneer is carried out by hard research. > Now I am reversing engneer the driver of Airgo device on Window. > > By the way, there is a strange assembly code from IDA Pro(a disassemble tool). > I can not understand it. Where should the Windows assembly code be discussed? > The assembly code is very simple, just write a value to ioremap space and check > whether it take affect. However it is different between the value > written(100h) and > the value checked(10h). > > The assembly code(from IDA Pro 5.0): > sub_13C00 proc near > > var_4= dword ptr -4 > arg_0= dword ptr 8 > > push esi > mov esi, [esp+arg_0] > mov al, [esi+24Ah] > test al, al > jz short loc_13C71 > > mov eax, [esi+31F4h] > push 100h ; Value > add eax, 3000h > push eax ; Register > call ds:WRITE_REGISTER_ULONG > mov eax, [esi+31F4h] > mov ecx, [eax+3000h] > mov [esp+arg_0], ecx > mov edx, [esp+arg_0] > and edx, 10h > cmp dl, 10h > jnz short loc_13C71 > > push edi > mov edi, ds:KeStallExecutionProcessor > lea esp, [esp+0] > > loc_13C50: ; MicroSeconds > push 32h > call edi ; KeStallExecutionProcessor > mov eax, [esi+31F4h] > mov eax, [eax+3000h] > mov [esp+4+arg_0], eax > mov ecx, [esp+4+arg_0] > and ecx, 10h > cmp cl, 10h > jz short loc_13C50 > > pop edi > > loc_13C71: > pop esi > retn 4 > sub_13C00 endp > > > > > > > > > Beyond that there are projects underway for Marvell PCI hardware, > > both the older 83xx and the newer 86xx stuff. The 83xx support > > (using the mrv8k driver) is farther along, while the 86xx stuff > > has made little progress. Marvell is at least somewhat friendly to > > having these supported, although their documentation is a bit lax. > > There are however (unmergeable) sample drivers available for each. > > > > Also lurking out there is support for the USB-based Prism2 devices. > > The linux-wlan project had support for these, but the kernel.org > > kernels do not. Hardware can be a bit hard to find... > > > > Well, enough food for thought for one message... :-) > > > > John > > -- > > John W. Linville > > linville at tuxdriver.com > > > > > > > > _______________________________________________ > > devel mailing list > > devel at linuxdriverproject.org > > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel > > > _______________________________________________ > devel mailing list > devel at linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel >
