linux-kernel - RE: Backporting other subsystems on Linux

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]

Date:	Wed, 2 Feb 2011 15:30:48 -0800
From:	"Zhao, Shanyu" <shanyu.zhao@...el.com>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>,
	Luis Rodriguez <Luis.Rodriguez@...eros.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Lance Zimmerman <lance.zimmerman@...eros.com>,
	Prem Kumar <Prem.Kumar@...eros.com>
Subject: RE: Backporting other subsystems on Linux

Hi Luis,

Thank you for the detailed explanation! 

I just started to explore potential options of backporting USB subsystems. Currently I'm not at the point where I'm ready to backport drivers. I'll work on that later.

>> The next question you have which you have not asked me yet is how do you
>address
>> cherry picks or patches not upstream. For that I have added three
>directories,
>> they are self described by their names with a URL to their respective
>README:
>>
>>   * linux-next-cherry-picks/ http://bit.ly/h76wrL
>>   * linux-next-pending/      http://bit.ly/eY4aCY
>>   * pending-stable/          http://bit.ly/dOsi7J
>>
>> What I really need to get to at some point is to use implement a
>> menuconfig thingy, we already drag the Kconfigs in but use config.mk for
>> makefile/dependency mapping. Patches welcomed.
Well, I actually didn't have that question in mind. :) I read the README files in these folders and I totally agree that there should not be patches under these 3 folders. I think compat-wireless should just fulfill the function of backporting a driver from a (stable) kernel to an old kernel. Not adding additional patches. Driver developers should strive to make important patches into the stable releases. 

>
>BTW one idea I have as of recent is to consider using Hudson for automatic
>build testing for compat-wireless but haven't yet mucked with it. Eventually
>this will be more and more important as time goes by and we support older
>kernels. The goal is to at the *very least* always support down to the last
>stable 2.6 kernel listed on kernel.org, today that is 2.6.27 and I think its
>a safe promise to commit to backporting *at least* to that kernel. We go
>beyond 2.6.27 though today.
This is a good idea!

Shanyu
--
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/