Re: [PATCH v3 01/11] tap: Remove tap_probe_vnet_hdr_len()

[Akihiko Odaki <akihiko.odaki@daynix.com>]

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.