linux-kernel - Re: Forward porting 2.4 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B665322.2060005@gawab.com>
Date:	Sun, 31 Jan 2010 20:05:54 -0800
From:	Justin Madru <jdm64@...ab.com>
To:	Willy Tarreau <w@....eu>
CC:	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Forward porting 2.4 driver

On 01/29/2010 12:36 PM, Willy Tarreau wrote:
> Hello,
>
> On Fri, Jan 29, 2010 at 12:29:52PM -0800, Justin Madru wrote:
>    
>> I have this Belkin router with the default firmware running 2.4.30.
>> Belkin provided the source code as specified by the GPL. I was wondering
>> how hard it would be to upgrade the kernel from 2.4.30 to 2.4.37.7. I
>> know that 2.6 would be extremely hard because the driver model has
>> changed so much. But, what changes happened between .30 and .37 that
>> would make it difficult to upgrade the code? Did the driver model or
>> other drastic changes happen? Could I just do a file diff; import the
>> new files Belkin added and update the make files and kconfig?
>>      
> it will very likely work even without any change. I have some drivers
> in my private tree which were written for various versions between
> 2.4.23 and 2.4.33, most of which apply without problem. In general
> the only conflicts you can get are in Config.in or the makefiles
> where the patch wants to add one line to enable the driver, because
> the context might have changed. But that's really obvious to fix.
>
>    
>> The CPU and wireless card are based on the Ralink 2880/2860 or something
>> like that.
>>      
> Well, if you have the 2.4 driver and the hardware, it could also be
> a nice exercise to try to port it to 2.6. It's not necessarily that
> much complicated, as there are several drivers which are compatible
> with both 2.4 and 2.6. They generally rely on some #define to rename
> some struct members or use different macros depending on versions.
>
> Regards,
> Willy
>
>
>    
Well, it's good that the driver might easily be updated to the latest 2.4.

I did a diff of the source code that was provided against 2.6.30. 
Unfortunately, it looks like there's been more changes to the code than 
simply adding drivers. Updates all across the tree have been made, some 
minor that would be an easy merge. But some seem to be more involved 
changes. Any suggestions on merging the code?

Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/