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: <86ee8fcc-e021-bb9f-fda6-a8e85cb1d9b4@intel.com>
Date:   Wed, 13 Apr 2022 14:26:23 +0000
From:   "Wang, Zhi A" <zhi.a.wang@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>
CC:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Christoph Hellwig <hch@....de>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> 
>> It seems Jani's makefile clean patch has already included this one, I can
>> just simply drop this one so that Christoph won't need to re-send everything.
>>
>> For the branch to move on, I am merging the patches and will re-generate the
>> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
>> gvt branches.
>>
>> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
>> gvt-staging branch until my pull request landed in drm-intel-next.
>>
>> Also our QA will test gvt-staging-branch before the pull request. I suppose
>> it will take one or two days.
> 
> When you are wrangling the branches it would be great if Christoph's
> series and it's minimal dependencies could be on a single branch that
> could reasonably be pulled to the VFIO tree too, thanks
> 
> Jason
> 

Hi Jason:

I am thinking about the process of merging process. Here are the dependence:

1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
go through drm.
My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 

2) Christoph's patches depends on my patches, but part of them are for VFIO.

a. If they are fully going through VFIO repo, they might have to wait my
patches to get landed first.

b. If only the GVT-g parts goes through GVT repo, and rest of them goes
through VFIO, the rest part still needs to wait.

What would be a better process?

Thanks,
Zhi.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ