[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze)
From: |
Max Reitz |
Subject: |
Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze) |
Date: |
Wed, 28 Oct 2020 10:28:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 28.10.20 09:11, Cornelia Huck wrote:
> On Tue, 27 Oct 2020 23:42:57 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> On Mon, 26 Oct 2020 at 19:39, Alex Williamson
>> <alex.williamson@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. :/
> 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.
Max
- [PULL 29/32] vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities, (continued)
- [PULL 29/32] vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities, Alex Williamson, 2020/10/26
- [PULL 30/32] s390x/pci: get zPCI function info from host, Alex Williamson, 2020/10/26
- [PULL 31/32] hw/vfio: Use lock guard macros, Alex Williamson, 2020/10/26
- [PULL 32/32] vfio: fix incorrect print type, Alex Williamson, 2020/10/26
- Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze), Peter Maydell, 2020/10/27
- Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze), Cornelia Huck, 2020/10/28
Re: [PULL 00/32] VFIO updates 2020-10-26 (for QEMU 5.2 soft-freeze), Peter Maydell, 2020/10/28