On Thu, 2018-12-06 at 20:40 -0700, Jason Gunthorpe wrote: > On Wed, Dec 05, 2018 at 03:30:38PM +0000, Arumugam, Kamenee wrote: > > > Subject: Re: [PATCH] hfi1verbs: Update rvt cq headers in rdma_core hfi1 provider > > > Since these need a kernel patch can you remark which kernel patch this is matched with? > > > > Here is the kernel patch: https://marc.info/?l=linux-rdma&m=154402265822649&w=2 > > > > > Also changes to kernel-headers should be split into their own patch created by the kernel-headers/update script as the first patch in your series. > > > > It there a README or documentation on the process for keeping kernel-headers in sync? > > Ah I wish there was, want to write one? > > > So is this the sequence?: > > - Patch the kernel > > * Does the patch need to land in an external tree? Which tree? > > - Use the update script to sync the kernel-headers > > Not quite. > > Patch *your* kernel with the required kernel patches for the series > > Run > > $ kernel-headers/update --not-final ../kernel HEAD > > This creates the 'Updated kernel headers' commit you need > > Apply the patches in your series. > > Push to github and tag your PR with 'needs-kernel-patch'. Post to the > mailing list with 'git send-email' > > When the kernel patch is accepted the you or the maintainer will do > 'git rebase' and exec instead of pick the first commit with: > > exec kernel-headers/update ../kernel 12345566 > > To build the final commit and remove the 'needs-kernel-patch' tag. > > That gets force pushed to the PR and the PR merged. > > This keeps the headers in sync between the two projects. > > Jason That seems entirely more complex than it should be. When you or I setup that level of complexity, it's not a big deal because we do this all the time. When you push that level of complexity onto the submitters, some of whom are going to be occasionally submitting uapi updates at best, then it's a recipe for botched updates. What if we create a git hook that tracks any updates to our local for- next branch and whenever we do an update that modifies anything in include/uapi/rdma it triggers a message to perform a headers update in rdma-core? Then we just jump over to that repo, git pull to make sure we're up to date with merges that have been done via the web interface, run kernel-headers/update ../kernel HEAD, git push, done. The only downside here is that the submitter will still need to have a header update patch in their pull request just so it will build/test prior to the official acceptance of the upstream patch. If I could do away with that too, I would. I'm just concerned that getting everyone out there to know how to use yet another tool and yet another exact sequence of operations is going to be a loosing battle. -- Doug Ledford <dledford@xxxxxxxxxx> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
