| Message ID | 20231011153944.39572-2-akihiko.odaki@daynix.com |
|---|---|
| State | New |
| Headers | show |
| Series | virtio-net RSS/hash report fixes | expand |
On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > It was necessary since an Linux older than 2.6.35 may implement the > virtio-net header but may not allow to change its length. Remove it > since such an old Linux is no longer supported. Where can I see this agreement? Thanks
On 2023/10/13 10:38, Jason Wang wrote: > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >> >> It was necessary since an Linux older than 2.6.35 may implement the >> virtio-net header but may not allow to change its length. Remove it >> since such an old Linux is no longer supported. > > Where can I see this agreement? docs/about/build-platforms.rst says: > The project aims to support the most recent major version at all times > for up to five years after its initial release. Support for the > previous major version will be dropped 2 years after the new major > version is released or when the vendor itself drops support, whichever > comes first. In this context, third-party efforts to extend the > lifetime of a distro are not considered, even when they are endorsed > by the vendor (eg. Debian LTS); the same is true of repositories that > contain packages backported from later releases (e.g. Debian > backports). Within each major release, only the most recent minor > release is considered. > > For the purposes of identifying supported software versions available > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > similar software versions. All of the previous major versions of these distributions ship far newer kernels. CentOS Stream 8 and RHEL 8 ship 4.18.0. Debian bullseye ships 5.10.0. Fedora 37 ships 6.5.6. openSUSE Leap 15.4 ships 5.14.21. SLES 12 ships 4.12.14. Ubuntu 20.04 ships 5.4.
On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > On 2023/10/13 10:38, Jason Wang wrote: > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > >> > >> It was necessary since an Linux older than 2.6.35 may implement the > >> virtio-net header but may not allow to change its length. Remove it > >> since such an old Linux is no longer supported. > > > > Where can I see this agreement? > > docs/about/build-platforms.rst says: > > The project aims to support the most recent major version at all times > > for up to five years after its initial release. Support for the > > previous major version will be dropped 2 years after the new major > > version is released or when the vendor itself drops support, whichever > > comes first. In this context, third-party efforts to extend the > > lifetime of a distro are not considered, even when they are endorsed > > by the vendor (eg. Debian LTS); the same is true of repositories that > > contain packages backported from later releases (e.g. Debian > > backports). Within each major release, only the most recent minor > > release is considered. > > > > For the purposes of identifying supported software versions available > > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > > similar software versions. Well it also says: """ If a platform is not listed here, it does not imply that QEMU won't work. If an unlisted platform has comparable software versions to a listed platform, there is every expectation that it will work. """ A lot of downstream have customized build scripts. And is something similar to such removal that has been done for other subsystems? Thanks > > All of the previous major versions of these distributions ship far newer > kernels. > > CentOS Stream 8 and RHEL 8 ship 4.18.0. > Debian bullseye ships 5.10.0. > Fedora 37 ships 6.5.6. > openSUSE Leap 15.4 ships 5.14.21. > SLES 12 ships 4.12.14. > Ubuntu 20.04 ships 5.4. >
On 2023/10/13 14:00, Jason Wang wrote: > On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >> >> On 2023/10/13 10:38, Jason Wang wrote: >>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>> >>>> It was necessary since an Linux older than 2.6.35 may implement the >>>> virtio-net header but may not allow to change its length. Remove it >>>> since such an old Linux is no longer supported. >>> >>> Where can I see this agreement? >> >> docs/about/build-platforms.rst says: >> > The project aims to support the most recent major version at all times >> > for up to five years after its initial release. Support for the >> > previous major version will be dropped 2 years after the new major >> > version is released or when the vendor itself drops support, whichever >> > comes first. In this context, third-party efforts to extend the >> > lifetime of a distro are not considered, even when they are endorsed >> > by the vendor (eg. Debian LTS); the same is true of repositories that >> > contain packages backported from later releases (e.g. Debian >> > backports). Within each major release, only the most recent minor >> > release is considered. >> > >> > For the purposes of identifying supported software versions available >> > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, >> > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship >> > similar software versions. > > Well it also says: > > """ > If a platform is not listed here, it does not imply that QEMU won't > work. If an unlisted platform has comparable software versions to a > listed platform, there is every expectation that it will work. > """ > > A lot of downstream have customized build scripts. Still Linux versions older than 2.6.35 do not look like "comparable software versions to a listed platform" in my opinion. > And is something similar to such removal that has been done for other > subsystems? With commit c42e77a90d ("qemu/osdep: Remove fallback for MAP_FIXED_NOREPLACE"), I remove the support for glibc older than 2.28. Linux 2.6.35 is even older.
On Fri, Oct 13, 2023 at 01:14:32PM +0900, Akihiko Odaki wrote: > On 2023/10/13 10:38, Jason Wang wrote: > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > It was necessary since an Linux older than 2.6.35 may implement the > > > virtio-net header but may not allow to change its length. Remove it > > > since such an old Linux is no longer supported. > > > > Where can I see this agreement? > > docs/about/build-platforms.rst says: > > The project aims to support the most recent major version at all times > > for up to five years after its initial release. Support for the > > previous major version will be dropped 2 years after the new major > > version is released or when the vendor itself drops support, whichever > > comes first. In this context, third-party efforts to extend the > > lifetime of a distro are not considered, even when they are endorsed > > by the vendor (eg. Debian LTS); the same is true of repositories that > > contain packages backported from later releases (e.g. Debian > > backports). Within each major release, only the most recent minor > > release is considered. > > > > For the purposes of identifying supported software versions available > > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > > similar software versions. > > All of the previous major versions of these distributions ship far newer > kernels. > > CentOS Stream 8 and RHEL 8 ship 4.18.0. Yes but RHEL7 is still in full support. > Debian bullseye ships 5.10.0. > Fedora 37 ships 6.5.6. > openSUSE Leap 15.4 ships 5.14.21. > SLES 12 ships 4.12.14. > Ubuntu 20.04 ships 5.4. It does not matter that a newer version is shipped. What matters is whether older one is still supported.
On 2023/10/13 22:55, Michael S. Tsirkin wrote: > On Fri, Oct 13, 2023 at 01:14:32PM +0900, Akihiko Odaki wrote: >> On 2023/10/13 10:38, Jason Wang wrote: >>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>> >>>> It was necessary since an Linux older than 2.6.35 may implement the >>>> virtio-net header but may not allow to change its length. Remove it >>>> since such an old Linux is no longer supported. >>> >>> Where can I see this agreement? >> >> docs/about/build-platforms.rst says: >>> The project aims to support the most recent major version at all times >>> for up to five years after its initial release. Support for the >>> previous major version will be dropped 2 years after the new major >>> version is released or when the vendor itself drops support, whichever >>> comes first. In this context, third-party efforts to extend the >>> lifetime of a distro are not considered, even when they are endorsed >>> by the vendor (eg. Debian LTS); the same is true of repositories that >>> contain packages backported from later releases (e.g. Debian >>> backports). Within each major release, only the most recent minor >>> release is considered. >>> >>> For the purposes of identifying supported software versions available >>> on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, >>> RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship >>> similar software versions. >> >> All of the previous major versions of these distributions ship far newer >> kernels. >> >> CentOS Stream 8 and RHEL 8 ship 4.18.0. > > Yes but RHEL7 is still in full support. I don't think so. The downstream (Red Hat) may still support it, but it's not supported by QEMU upstream according to docs/about/build-platforms.rst. > >> Debian bullseye ships 5.10.0. >> Fedora 37 ships 6.5.6. >> openSUSE Leap 15.4 ships 5.14.21. >> SLES 12 ships 4.12.14. >> Ubuntu 20.04 ships 5.4. > > It does not matter that a newer version is shipped. What matters is > whether older one is still supported. These versions should be the oldest supported versions that match with the description in docs/about/build-platforms.rst.
On Fri, Oct 13, 2023 at 02:26:03PM +0900, Akihiko Odaki wrote: > On 2023/10/13 14:00, Jason Wang wrote: > > On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > On 2023/10/13 10:38, Jason Wang wrote: > > > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > > > > > It was necessary since an Linux older than 2.6.35 may implement the > > > > > virtio-net header but may not allow to change its length. Remove it > > > > > since such an old Linux is no longer supported. > > > > > > > > Where can I see this agreement? > > > > > > docs/about/build-platforms.rst says: > > > > The project aims to support the most recent major version at all times > > > > for up to five years after its initial release. Support for the > > > > previous major version will be dropped 2 years after the new major > > > > version is released or when the vendor itself drops support, whichever > > > > comes first. In this context, third-party efforts to extend the > > > > lifetime of a distro are not considered, even when they are endorsed > > > > by the vendor (eg. Debian LTS); the same is true of repositories that > > > > contain packages backported from later releases (e.g. Debian > > > > backports). Within each major release, only the most recent minor > > > > release is considered. > > > > > > > > For the purposes of identifying supported software versions available > > > > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > > > > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > > > > similar software versions. > > > > Well it also says: > > > > """ > > If a platform is not listed here, it does not imply that QEMU won't > > work. If an unlisted platform has comparable software versions to a > > listed platform, there is every expectation that it will work. > > """ > > > > A lot of downstream have customized build scripts. > > Still Linux versions older than 2.6.35 do not look like "comparable software > versions to a listed platform" in my opinion. This is fine - I would be ok to replace support with an error message and failure. Not checking that a capability is supported however isn't a good idea. And once we do - do we still gain anything by not working around that? > > And is something similar to such removal that has been done for other > > subsystems? > > With commit c42e77a90d ("qemu/osdep: Remove fallback for > MAP_FIXED_NOREPLACE"), I remove the support for glibc older than 2.28. Linux > 2.6.35 is even older.
On 2023/10/13 23:17, Michael S. Tsirkin wrote: > On Fri, Oct 13, 2023 at 02:26:03PM +0900, Akihiko Odaki wrote: >> On 2023/10/13 14:00, Jason Wang wrote: >>> On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>> >>>> On 2023/10/13 10:38, Jason Wang wrote: >>>>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>>>> >>>>>> It was necessary since an Linux older than 2.6.35 may implement the >>>>>> virtio-net header but may not allow to change its length. Remove it >>>>>> since such an old Linux is no longer supported. >>>>> >>>>> Where can I see this agreement? >>>> >>>> docs/about/build-platforms.rst says: >>>> > The project aims to support the most recent major version at all times >>>> > for up to five years after its initial release. Support for the >>>> > previous major version will be dropped 2 years after the new major >>>> > version is released or when the vendor itself drops support, whichever >>>> > comes first. In this context, third-party efforts to extend the >>>> > lifetime of a distro are not considered, even when they are endorsed >>>> > by the vendor (eg. Debian LTS); the same is true of repositories that >>>> > contain packages backported from later releases (e.g. Debian >>>> > backports). Within each major release, only the most recent minor >>>> > release is considered. >>>> > >>>> > For the purposes of identifying supported software versions available >>>> > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, >>>> > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship >>>> > similar software versions. >>> >>> Well it also says: >>> >>> """ >>> If a platform is not listed here, it does not imply that QEMU won't >>> work. If an unlisted platform has comparable software versions to a >>> listed platform, there is every expectation that it will work. >>> """ >>> >>> A lot of downstream have customized build scripts. >> >> Still Linux versions older than 2.6.35 do not look like "comparable software >> versions to a listed platform" in my opinion. > > > This is fine - I would be ok to replace support with an error message > and failure. Not checking that a capability is supported however > isn't a good idea. And once we do - do we still gain anything by > not working around that? tap does still check if setting the header length succeeds so it should be fine.
On Fri, Oct 13, 2023 at 11:22:10PM +0900, Akihiko Odaki wrote: > On 2023/10/13 23:17, Michael S. Tsirkin wrote: > > On Fri, Oct 13, 2023 at 02:26:03PM +0900, Akihiko Odaki wrote: > > > On 2023/10/13 14:00, Jason Wang wrote: > > > > On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > > > > > On 2023/10/13 10:38, Jason Wang wrote: > > > > > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > > > > > > > > > It was necessary since an Linux older than 2.6.35 may implement the > > > > > > > virtio-net header but may not allow to change its length. Remove it > > > > > > > since such an old Linux is no longer supported. > > > > > > > > > > > > Where can I see this agreement? > > > > > > > > > > docs/about/build-platforms.rst says: > > > > > > The project aims to support the most recent major version at all times > > > > > > for up to five years after its initial release. Support for the > > > > > > previous major version will be dropped 2 years after the new major > > > > > > version is released or when the vendor itself drops support, whichever > > > > > > comes first. In this context, third-party efforts to extend the > > > > > > lifetime of a distro are not considered, even when they are endorsed > > > > > > by the vendor (eg. Debian LTS); the same is true of repositories that > > > > > > contain packages backported from later releases (e.g. Debian > > > > > > backports). Within each major release, only the most recent minor > > > > > > release is considered. > > > > > > > > > > > > For the purposes of identifying supported software versions available > > > > > > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > > > > > > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > > > > > > similar software versions. > > > > > > > > Well it also says: > > > > > > > > """ > > > > If a platform is not listed here, it does not imply that QEMU won't > > > > work. If an unlisted platform has comparable software versions to a > > > > listed platform, there is every expectation that it will work. > > > > """ > > > > > > > > A lot of downstream have customized build scripts. > > > > > > Still Linux versions older than 2.6.35 do not look like "comparable software > > > versions to a listed platform" in my opinion. > > > > > > This is fine - I would be ok to replace support with an error message > > and failure. Not checking that a capability is supported however > > isn't a good idea. And once we do - do we still gain anything by > > not working around that? > > tap does still check if setting the header length succeeds so it should be > fine. It asserts though doesn't it? Hardly user friendly ...
On 2023/10/13 23:32, Michael S. Tsirkin wrote: > On Fri, Oct 13, 2023 at 11:22:10PM +0900, Akihiko Odaki wrote: >> On 2023/10/13 23:17, Michael S. Tsirkin wrote: >>> On Fri, Oct 13, 2023 at 02:26:03PM +0900, Akihiko Odaki wrote: >>>> On 2023/10/13 14:00, Jason Wang wrote: >>>>> On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>>>> >>>>>> On 2023/10/13 10:38, Jason Wang wrote: >>>>>>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>>>>>> >>>>>>>> It was necessary since an Linux older than 2.6.35 may implement the >>>>>>>> virtio-net header but may not allow to change its length. Remove it >>>>>>>> since such an old Linux is no longer supported. >>>>>>> >>>>>>> Where can I see this agreement? >>>>>> >>>>>> docs/about/build-platforms.rst says: >>>>>> > The project aims to support the most recent major version at all times >>>>>> > for up to five years after its initial release. Support for the >>>>>> > previous major version will be dropped 2 years after the new major >>>>>> > version is released or when the vendor itself drops support, whichever >>>>>> > comes first. In this context, third-party efforts to extend the >>>>>> > lifetime of a distro are not considered, even when they are endorsed >>>>>> > by the vendor (eg. Debian LTS); the same is true of repositories that >>>>>> > contain packages backported from later releases (e.g. Debian >>>>>> > backports). Within each major release, only the most recent minor >>>>>> > release is considered. >>>>>> > >>>>>> > For the purposes of identifying supported software versions available >>>>>> > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, >>>>>> > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship >>>>>> > similar software versions. >>>>> >>>>> Well it also says: >>>>> >>>>> """ >>>>> If a platform is not listed here, it does not imply that QEMU won't >>>>> work. If an unlisted platform has comparable software versions to a >>>>> listed platform, there is every expectation that it will work. >>>>> """ >>>>> >>>>> A lot of downstream have customized build scripts. >>>> >>>> Still Linux versions older than 2.6.35 do not look like "comparable software >>>> versions to a listed platform" in my opinion. >>> >>> >>> This is fine - I would be ok to replace support with an error message >>> and failure. Not checking that a capability is supported however >>> isn't a good idea. And once we do - do we still gain anything by >>> not working around that? >> >> tap does still check if setting the header length succeeds so it should be >> fine. > > It asserts though doesn't it? Hardly user friendly ... It prints an error message so the user should be able to figure out what's missing: fprintf(stderr, "TUNSETVNETHDRSZ ioctl() failed: %s. Exiting.\n", strerror(errno));
On Fri, Oct 13, 2023 at 11:34:54PM +0900, Akihiko Odaki wrote: > On 2023/10/13 23:32, Michael S. Tsirkin wrote: > > On Fri, Oct 13, 2023 at 11:22:10PM +0900, Akihiko Odaki wrote: > > > On 2023/10/13 23:17, Michael S. Tsirkin wrote: > > > > On Fri, Oct 13, 2023 at 02:26:03PM +0900, Akihiko Odaki wrote: > > > > > On 2023/10/13 14:00, Jason Wang wrote: > > > > > > On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > > > > > > > > > On 2023/10/13 10:38, Jason Wang wrote: > > > > > > > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > > > > > > > > > > > > > > > > > It was necessary since an Linux older than 2.6.35 may implement the > > > > > > > > > virtio-net header but may not allow to change its length. Remove it > > > > > > > > > since such an old Linux is no longer supported. > > > > > > > > > > > > > > > > Where can I see this agreement? > > > > > > > > > > > > > > docs/about/build-platforms.rst says: > > > > > > > > The project aims to support the most recent major version at all times > > > > > > > > for up to five years after its initial release. Support for the > > > > > > > > previous major version will be dropped 2 years after the new major > > > > > > > > version is released or when the vendor itself drops support, whichever > > > > > > > > comes first. In this context, third-party efforts to extend the > > > > > > > > lifetime of a distro are not considered, even when they are endorsed > > > > > > > > by the vendor (eg. Debian LTS); the same is true of repositories that > > > > > > > > contain packages backported from later releases (e.g. Debian > > > > > > > > backports). Within each major release, only the most recent minor > > > > > > > > release is considered. > > > > > > > > > > > > > > > > For the purposes of identifying supported software versions available > > > > > > > > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > > > > > > > > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > > > > > > > > similar software versions. > > > > > > > > > > > > Well it also says: > > > > > > > > > > > > """ > > > > > > If a platform is not listed here, it does not imply that QEMU won't > > > > > > work. If an unlisted platform has comparable software versions to a > > > > > > listed platform, there is every expectation that it will work. > > > > > > """ > > > > > > > > > > > > A lot of downstream have customized build scripts. > > > > > > > > > > Still Linux versions older than 2.6.35 do not look like "comparable software > > > > > versions to a listed platform" in my opinion. > > > > > > > > > > > > This is fine - I would be ok to replace support with an error message > > > > and failure. Not checking that a capability is supported however > > > > isn't a good idea. And once we do - do we still gain anything by > > > > not working around that? > > > > > > tap does still check if setting the header length succeeds so it should be > > > fine. > > > > It asserts though doesn't it? Hardly user friendly ... > > It prints an error message so the user should be able to figure out what's > missing: > fprintf(stderr, "TUNSETVNETHDRSZ ioctl() failed: %s. Exiting.\n", > strerror(errno)); OK. Acked-by: Michael S. Tsirkin <mst@redhat.com>
On Fri, Oct 13, 2023 at 1:26 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > > On 2023/10/13 14:00, Jason Wang wrote: > > On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > >> > >> On 2023/10/13 10:38, Jason Wang wrote: > >>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: > >>>> > >>>> It was necessary since an Linux older than 2.6.35 may implement the > >>>> virtio-net header but may not allow to change its length. Remove it > >>>> since such an old Linux is no longer supported. > >>> > >>> Where can I see this agreement? > >> > >> docs/about/build-platforms.rst says: > >> > The project aims to support the most recent major version at all times > >> > for up to five years after its initial release. Support for the > >> > previous major version will be dropped 2 years after the new major > >> > version is released or when the vendor itself drops support, whichever > >> > comes first. In this context, third-party efforts to extend the > >> > lifetime of a distro are not considered, even when they are endorsed > >> > by the vendor (eg. Debian LTS); the same is true of repositories that > >> > contain packages backported from later releases (e.g. Debian > >> > backports). Within each major release, only the most recent minor > >> > release is considered. > >> > > >> > For the purposes of identifying supported software versions available > >> > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, > >> > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship > >> > similar software versions. > > > > Well it also says: > > > > """ > > If a platform is not listed here, it does not imply that QEMU won't > > work. If an unlisted platform has comparable software versions to a > > listed platform, there is every expectation that it will work. > > """ > > > > A lot of downstream have customized build scripts. > > Still Linux versions older than 2.6.35 do not look like "comparable > software versions to a listed platform" in my opinion. Linux provides ABI compatibility so I don't know why, unless there is a strong dependency on a specific new syscall introduced after 2.6.35. > > > And is something similar to such removal that has been done for other > > subsystems? > > With commit c42e77a90d ("qemu/osdep: Remove fallback for > MAP_FIXED_NOREPLACE"), I remove the support for glibc older than 2.28. > Linux 2.6.35 is even older. > Ok, this explains things a little bit. Btw, we also have soliars support for TAP, time to drop that as well? Thanks
On 2023/10/16 14:25, Jason Wang wrote: > On Fri, Oct 13, 2023 at 1:26 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >> >> On 2023/10/13 14:00, Jason Wang wrote: >>> On Fri, Oct 13, 2023 at 12:14 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>> >>>> On 2023/10/13 10:38, Jason Wang wrote: >>>>> On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >>>>>> >>>>>> It was necessary since an Linux older than 2.6.35 may implement the >>>>>> virtio-net header but may not allow to change its length. Remove it >>>>>> since such an old Linux is no longer supported. >>>>> >>>>> Where can I see this agreement? >>>> >>>> docs/about/build-platforms.rst says: >>>> > The project aims to support the most recent major version at all times >>>> > for up to five years after its initial release. Support for the >>>> > previous major version will be dropped 2 years after the new major >>>> > version is released or when the vendor itself drops support, whichever >>>> > comes first. In this context, third-party efforts to extend the >>>> > lifetime of a distro are not considered, even when they are endorsed >>>> > by the vendor (eg. Debian LTS); the same is true of repositories that >>>> > contain packages backported from later releases (e.g. Debian >>>> > backports). Within each major release, only the most recent minor >>>> > release is considered. >>>> > >>>> > For the purposes of identifying supported software versions available >>>> > on Linux, the project will look at CentOS, Debian, Fedora, openSUSE, >>>> > RHEL, SLES and Ubuntu LTS. Other distros will be assumed to ship >>>> > similar software versions. >>> >>> Well it also says: >>> >>> """ >>> If a platform is not listed here, it does not imply that QEMU won't >>> work. If an unlisted platform has comparable software versions to a >>> listed platform, there is every expectation that it will work. >>> """ >>> >>> A lot of downstream have customized build scripts. >> >> Still Linux versions older than 2.6.35 do not look like "comparable >> software versions to a listed platform" in my opinion. > > Linux provides ABI compatibility so I don't know why, unless there is > a strong dependency on a specific new syscall introduced after 2.6.35. This patch drops a pre-check for ioctl introduced with 2.6.35. > >> >>> And is something similar to such removal that has been done for other >>> subsystems? >> >> With commit c42e77a90d ("qemu/osdep: Remove fallback for >> MAP_FIXED_NOREPLACE"), I remove the support for glibc older than 2.28. >> Linux 2.6.35 is even older. >> > > Ok, this explains things a little bit. Btw, we also have soliars > support for TAP, time to drop that as well? Do you mean Solaris? Honestly I don't know. I don't think anyone dares to use QEMU on Solaris (or to use Solaris at all), but apparently Oracle has not abandoned it yet.
diff --git a/net/tap_int.h b/net/tap_int.h index 547f8a5a28..ff7ab23ad7 100644 --- a/net/tap_int.h +++ b/net/tap_int.h @@ -35,7 +35,6 @@ ssize_t tap_read_packet(int tapfd, uint8_t *buf, int maxlen); void tap_set_sndbuf(int fd, const NetdevTapOptions *tap, Error **errp); int tap_probe_vnet_hdr(int fd, Error **errp); -int tap_probe_vnet_hdr_len(int fd, int len); int tap_probe_has_ufo(int fd); void tap_fd_set_offload(int fd, int csum, int tso4, int tso6, int ecn, int ufo); void tap_fd_set_vnet_hdr_len(int fd, int len); diff --git a/net/tap-bsd.c b/net/tap-bsd.c index 4c98fdd337..bcd9e894a8 100644 --- a/net/tap-bsd.c +++ b/net/tap-bsd.c @@ -212,11 +212,6 @@ int tap_probe_has_ufo(int fd) return 0; } -int tap_probe_vnet_hdr_len(int fd, int len) -{ - return 0; -} - void tap_fd_set_vnet_hdr_len(int fd, int len) { } diff --git a/net/tap-linux.c b/net/tap-linux.c index f54f308d35..985287816e 100644 --- a/net/tap-linux.c +++ b/net/tap-linux.c @@ -173,26 +173,6 @@ int tap_probe_has_ufo(int fd) return 1; } -/* Verify that we can assign given length */ -int tap_probe_vnet_hdr_len(int fd, int len) -{ - int orig; - if (ioctl(fd, TUNGETVNETHDRSZ, &orig) == -1) { - return 0; - } - if (ioctl(fd, TUNSETVNETHDRSZ, &len) == -1) { - return 0; - } - /* Restore original length: we can't handle failure. */ - if (ioctl(fd, TUNSETVNETHDRSZ, &orig) == -1) { - fprintf(stderr, "TUNGETVNETHDRSZ ioctl() failed: %s. Exiting.\n", - strerror(errno)); - abort(); - return -errno; - } - return 1; -} - void tap_fd_set_vnet_hdr_len(int fd, int len) { if (ioctl(fd, TUNSETVNETHDRSZ, &len) == -1) { diff --git a/net/tap-solaris.c b/net/tap-solaris.c index 38e15028bf..6ad79fecad 100644 --- a/net/tap-solaris.c +++ b/net/tap-solaris.c @@ -216,11 +216,6 @@ int tap_probe_has_ufo(int fd) return 0; } -int tap_probe_vnet_hdr_len(int fd, int len) -{ - return 0; -} - void tap_fd_set_vnet_hdr_len(int fd, int len) { } diff --git a/net/tap-stub.c b/net/tap-stub.c index a0fa25804b..422257668c 100644 --- a/net/tap-stub.c +++ b/net/tap-stub.c @@ -47,11 +47,6 @@ int tap_probe_has_ufo(int fd) return 0; } -int tap_probe_vnet_hdr_len(int fd, int len) -{ - return 0; -} - void tap_fd_set_vnet_hdr_len(int fd, int len) { } diff --git a/net/tap.c b/net/tap.c index c6639d9f20..0403729739 100644 --- a/net/tap.c +++ b/net/tap.c @@ -248,11 +248,7 @@ static bool tap_has_vnet_hdr(NetClientState *nc) static bool tap_has_vnet_hdr_len(NetClientState *nc, int len) { - TAPState *s = DO_UPCAST(TAPState, nc, nc); - - assert(nc->info->type == NET_CLIENT_DRIVER_TAP); - - return !!tap_probe_vnet_hdr_len(s->fd, len); + return tap_has_vnet_hdr(nc); } static int tap_get_vnet_hdr_len(NetClientState *nc) @@ -419,9 +415,7 @@ static TAPState *net_tap_fd_init(NetClientState *peer, * Make sure host header length is set correctly in tap: * it might have been modified by another instance of qemu. */ - if (tap_probe_vnet_hdr_len(s->fd, s->host_vnet_hdr_len)) { - tap_fd_set_vnet_hdr_len(s->fd, s->host_vnet_hdr_len); - } + tap_fd_set_vnet_hdr_len(s->fd, s->host_vnet_hdr_len); tap_read_poll(s, true); s->vhost_net = NULL;
It was necessary since an Linux older than 2.6.35 may implement the virtio-net header but may not allow to change its length. Remove it since such an old Linux is no longer supported. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> --- net/tap_int.h | 1 - net/tap-bsd.c | 5 ----- net/tap-linux.c | 20 -------------------- net/tap-solaris.c | 5 ----- net/tap-stub.c | 5 ----- net/tap.c | 10 ++-------- 6 files changed, 2 insertions(+), 44 deletions(-)