netdev - Re: phy timestamping "library"

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] [day] [month] [year] [list]

Message-ID: <20191128082351.GA3705@localhost>
Date:   Thu, 28 Nov 2019 00:23:51 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Michael Walle <michael@...le.cc>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>
Subject: Re: phy timestamping "library"

On Tue, Nov 26, 2019 at 07:00:02PM +0100, Michael Walle wrote:
> So what I'd like to have in a seperate "library" is the following:
>  - skb queues handling
>  - rx timestamp pool handling
>  - rx timestamp timeout handling
>  - skb delivery to the network stack on either match or timeout

I would resist the temptation to turn this into a "library", unless
there is a clear benefit.

> Now I have the following problem: the original driver attaches more data
> to the timestamp, as is my driver; this data is used by the match
> function.

...

> But how can I give that memory to the lib in phyts_init() and how can
> phyts_init() populate its rx_pool_data. Or maybe I'm getting it all
> wrong and there is a better way ;)

Sounds like the re-factoring of a couple of lists into a "library" is
not worth the effort.  The differences in the matching logic will make
the "library" baroque.

I suggest not over-engineering your new driver.  In any case, it is
hard to say without seeing the patches.

Thanks,
Richard