On Wed, 28 Oct 2020 10:28:39 +0100
Max Reitz <mre...@redhat.com> wrote:
> On 28.10.20 09:11, Cornelia Huck wrote:
> > On Tue, 27 Oct 2020 23:42:57 +0000
> > Peter Maydell <peter.mayd...@linaro.org> wrote:
> >
> >> On Mon, 26 Oct 2020 at 19:39, Alex Williamson
> >> <alex.william...@redhat.com> wrote:
> >>> ----------------------------------------------------------------
> >>> VFIO update 2020-10-26
> >>>
> >>> * Migration support (Kirti Wankhede)
> >>> * s390 DMA limiting (Matthew Rosato)
> >>> * zPCI hardware info (Matthew Rosato)
> >>> * Lock guard (Amey Narkhede)
> >>> * Print fixes (Zhengui li)
> >>
> >> I get a conflict here in
> >> include/standard-headers/linux/fuse.h:
> >>
> >> ++<<<<<<< HEAD
> >> +#define FUSE_ATTR_FLAGS (1 << 27)
> >> ++=======
> >> + #define FUSE_SUBMOUNTS (1 << 27)
> >> ++>>>>>>> remotes/awilliam/tags/vfio-update-20201026.0
> >>
> >> I assume these should not both be trying to use the same value,
> >> so something has gone wrong somewhere. The conflicting commit
> >> now in master is Max's 97d741cc96dd08 ("linux/fuse.h: Pull in from Linux").
> >>
> >> Can you sort out the correct resolution between you, please?
> >> (My guess is that Max's commit is the erroneous one because
> >> it doesn't look like it was created via a standard update
> >> from the kernel headers.)
> >
> > We should never change things in the synced headers other than via a
> > headers update (excluding fixups of prior messes.) I'm pointing it out
> > whenever I see something like that happening, but nobody is going to
> > catch all of those.
>
> Well, it was a kernel update. Just based on a preliminary version of
> the kernel part of the FUSE submount feature.
>
> It was clear that the kernel part would have to be merged before the
> qemu/virtiofsd series, and that did happen, but Miklos (the FUSE
> maintainer) fixed some things on top while doing so, an that included
> changing the flag in question. As Adam wrote, I noted that I would thus
> have to write a v2 of the virtiofsd series.
>
> Unfortunately, that all was a bit buried in the thread, so I suppose for
> Dave it looked like the kernel series was applied, so the virtiofsd
> series could go in, too. And I in turn didn't catch that. :/
Yeah, things like that happen, especially if explanations are buried
deeply somewhere :/
>
> > Is there any place where we can have some kind of automatic check on a
> > pull request for that kind of stuff? We'd need to formalize an "update
> > headers" commit message, or maybe have the update script write some
> > kind of "last updated" file?
> It would also need to actually check against the kernel tree, because,
> well, I did use the script. Just against a kernel tree that never came
> to master.
Hm. That's probably hard to get right, unless we require all updates
to be against a tagged kernel (-rc) version. Not sure if that's too
strict.
