netdev - Re: [PATCH net-next RFC v2] Add NDOs for hardware timestamp get/set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230404123015.wzv5l5owgkppoarr@skbuf>
Date:   Tue, 4 Apr 2023 15:30:15 +0300
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Max Georgiev <glipus@...il.com>
Cc:     kory.maincent@...tlin.com, kuba@...nel.org, netdev@...r.kernel.org,
        maxime.chevallier@...tlin.com,
        Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next RFC v2] Add NDOs for hardware timestamp get/set

On Mon, Apr 03, 2023 at 09:42:09AM -0600, Max Georgiev wrote:
> > The conversion per se looks almost in line with what I was expecting to
> > see, except for the comments. I guess you can convert a single driver
> > first (e1000 seems fine), to get the API merged, then more people could
> > work in parallel?
> 
> The conversions are going to be easy (that was the point of adding these NDO
> functions). But there is still a problem of validating these
> conversions with testing.
> Unfortunately I don't have an e1000 card available to validate this conversion.
> I'll let you and Jakub decide what will be the best strategy here.

If you can convert one of the drivers under drivers/net/ethernet/freescale/
with the exception of fec_main.c, or net/dsa/ + drivers/net/dsa/sja1105/
or drivers/net/dsa/mv88e6xxx/, then I can help with testing.

By the way, after inspecting the kernel code a bit more, it also looks
like we need to convert vlan_dev_ioctl() and bond_eth_ioctl() to
something compatible with lower interfaces using the new and the old
API, before converting any driver. Otherwise we'll need to do that later
anyway, when regression reports start coming in. So these 2 are
non-optional whatever you do.