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 > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > On 2023/10/13 10:38, Jason Wang wrote: > > > > > > > > On Wed, Oct 11, 2023 at 11:40 PM Akihiko Odaki > > > > > > > > <[email protected]> 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 <[email protected]>
