On Wed, May 31 2023, Anthony Krowiak <akrow...@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 <akrow...@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.)
