Re: [bitbake-devel] an idea about parallel doing do_patch

["Khem Raj" <raj.khem@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1635 bytes --]



On 9/7/20 1:37 AM, Mikko Rapeli wrote:
> Hi,
> 
> On Mon, Sep 07, 2020 at 01:27:29AM -0700, zhangyifan46 via lists.openembedded.org wrote:
>> In our peoject,we have suffered a lot from long duration of do_patch of linux kernel(3000+ patches). I found that one do_patch task uses only one process. So I modify a llittle do do_patch task. Here is my idea:
>> 1.analyse the patches,only getting the modified files of each patch.
>> 2.cluster all patches according to the files modified( patch no.1 modifies file A,B ,patch no.2 modifies file A, patch no.3 modifies file C,then we cluster patch no.1 and no.2 as  a group, patch no.3 as another group) , here I use union-find to do the cluster
>> 3.assign one group on one process
>> But I met the problem of probabilistic missing patches.
>> Anyone has any comments about my idea?
> 
> I think having large patch sets in meta layers and applied with bitbake are not the
> right solution. I would create a custom git repo and branch for large forks/branches
> like this.
> 

right, I think thousands of patches via patch management tools like
quilt is going to be cumbersome, I think best approach here would be to
fork kernel tree and maintain your patches on a branch. It will ease out
maintenance as well as build times. Ofcourse it means you have to adopt
a good process to manage your kernel branch so it does not spin into a
maintenance problems either.

> Possibly it could also be possible to apply patches with git through mbox files, but
> I don't think this will much faster than bitbake.


> 
> Hope this helps,
> 
> -Mikko
> 
>>
>>
>> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]