Re: [PATCH 1/2] linux-headers: Update with vfio_ap IRQ index mapping

[Cornelia Huck <cohuck@redhat.com>]

On Wed, May 31 2023, Anthony Krowiak <akrowiak@linux.ibm.com> wrote:

> On 5/30/23 8:56 PM, Matthew Rosato wrote:
>> On 5/30/23 6:55 PM, Tony Krowiak wrote:
>>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>>> ---
>>>   linux-headers/linux/vfio.h | 9 +++++++++
>>>   1 file changed, 9 insertions(+)
>> 
>> Worth nothing here that linux-headers patches should be generated using scripts/update-linux-headers.sh.
>> 
>> Since this linux-headers update includes changes that aren't merged into the kernel yet, I would still use update-linux-headers.sh -- but also include in the commit message that this is a placeholder patch that includes unmerged uapi changes.  Then once the kernel changes merge you can just have a proper linux-headers update patch in a subsequent qemu series.
>
> I guess I do not understand the procedure here. I first determined the 
> latest kernel release in which the vfio.h file was updated with the 
> following command:
> git log --oneline origin/master -- linux-headers/linux/vfio.h
>
> According to the git log, the vfio.h file was last updated in kernel 
> v6.3-rc5. I cloned that kernel from 
> git.kernel.org/pub/scm/linux/kernel/git/stable and checked out kernel 
> 6.3-rc5. I then made the changes to the linux-headers/linux/vfio.h file 
> and ran the update-linux-headers.sh script and created this patch from 
> that. Where did I go wrong?

I think your procedure is fine for changes that are local to a single
header file. The one thing I'd recommend is to put an explicit "dummy
patch, to be replaced by a proper headers update" note into the patch,
so that it doesn't get merged by accident.

(For complex changes, headers update + explicit note might be better,
but the simple approach works in most cases.)