On Wed, 21 Jan 2026 at 14:02, Cédric Le Goater <[email protected]> wrote:
>
> On 1/21/26 12:41, Shameer Kolothum wrote:
> > Mainly for adding support for VFIO DMABUF. While at it, update all
> > headers.
> >
> > The header update breaks virtio-net due to virtio_net_hdr_v1_hash
> > changes. Include the virtio-net changes to avoid build and bisect
> > failures.
> >
> > Cc: Michael S. Tsirkin <[email protected]>
> > Cc: Jason Wang <[email protected]>
> > Tested-by: Nicolin Chen <[email protected]>
> > Reviewed-by: Cédric Le Goater <[email protected]>
> > Signed-off-by: Shameer Kolothum <[email protected]>
> > ---
> >   hw/net/virtio-net.c                           |  11 +-
>
> Recent commit 503eb470e087 ("scripts/checkpatch: more checks on files
> imported from Linux") added a check on the imported files and checkpatch
> now complains with :
>
>    ERROR: headers imported from Linux should be self-contained in a patch 
> with no other changes
>    #101: FILE: include/standard-headers/drm/drm_fourcc.h:978:
>      *               2 = Gob Height 8, Turing+ Page Kind mapping
>
>
> I suspect there is an error in the name of the file in question.
>
> Anyhow, feedbacks are welcome because I doubt this check is
> valid in this situation and I am ready to apply this change
> as is.

The virtio-net.c change should not be in here. The change should
be staged in a way that virtio-net.c gets updated first so it
can cope with either the old header or the new header.

But it looks to me like this is a bug in the Linux headers:
they seem to have changed in a non-backwards compatible way,
and possibly even in a way that makes it not possible for
userspace code to use ifdefs to handle "maybe the header
is the old version or the new version".

Ideally the kernel headers should be fixed upstream to
revert their compatibility break, I think.

thanks
-- PMM

Reply via email to