I'd suggest to do the single change in virtio-net.c with RSC definitions
from updated linux headers.
I can send respective patch if you want

On Mon, Apr 27, 2020 at 12:18 PM Michael S. Tsirkin <m...@redhat.com> wrote:

> On Mon, Apr 27, 2020 at 11:10:29AM +0200, Cornelia Huck wrote:
> > On Mon, 27 Apr 2020 16:41:30 +0800
> > Jason Wang <jasow...@redhat.com> wrote:
> >
> > >
> > > On 2020/4/27 下午3:33, Cornelia Huck wrote:
> > > > Hi,
> > > >
> > > > I'm currently trying to prepare a linux-headers update to 5.7-rc3,
> > > > which adds the definition of VIRTIO_NET_HDR_F_RSC_INFO.
> > > >
> > > > Unfortunately, this breaks the build of virtio-net, because now
> > > > virtio_net_rsc_ext_num_{packets,dupacks} are undefined (they are
> > > > guarded by existence of VIRTIO_NET_HDR_F_RSC_INFO).
> > > >
> > > > What is the right way to fix this? Remove the constants that are now
> > > > provided by the header and keep the definitions of
> > > > virtio_net_rsc_ext_num_{packets,dupacks}?
> > >
> > >
> > > We probably need to add a version of the above function when
> > > VIRTIO_NET_HDR_F_RSC_INFO is defined as attached.
> > >
> > > But I fail to understand why we need a fallback when
> > > VIRTIO_NET_HDR_F_RSC_INFO is not defined.
> >
> > Yes, the current code in virtio-net looks a bit odd, which is why I
> > asked.
> >
> > I see two options:
> > - do the change you proposed, do the headers update, and then rip out
> >    the compat handling
> > - do the above in a single step
> >
> > I'd prefer the second option.
>
> Slight preference for 1st one but both are ok.
>
> > >
> > > Thanks
> > >
> > >
> > > >
> > > > [I'd like to queue a headers update as soon as possible, as the whole
> > > > s390 protected virt stuff depends on it...]
> > > >
> > > >
>
>

Reply via email to