linux-kernel - Re: [PATCH net-next v2 7/8] net: stmmac: xgmac: Complete FPE support

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: <20241018180023.000045d8@gmail.com>
Date: Fri, 18 Oct 2024 18:00:23 +0800
From: Furong Xu <0x1207@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Andrew
 Lunn <andrew@...n.ch>, Simon Horman <horms@...nel.org>, Serge Semin
 <fancer.lancer@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Jose Abreu <joabreu@...opsys.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
 Abeni <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
 xfr@...look.com
Subject: Re: [PATCH net-next v2 7/8] net: stmmac: xgmac: Complete FPE
 support

On Fri, 18 Oct 2024 12:13:21 +0300, Vladimir Oltean <olteanv@...il.com> wrote:

> This is much better in terms of visibility into the change.
> 
> Though I cannot stop thinking that this implementation design:
> 
> stmmac_fpe_configure()
> -> stmmac_do_void_callback()
>    -> fpe_ops->fpe_configure()  
>       /                    \
>      /                      \
>     v                        v
> dwmac5_fpe_configure   dwxgmac3_fpe_configure
>      \                      /
>       \                    /
>        v                  v
>        common_fpe_configure()
> 
> is, pardon the expression, stuffy.
> 
> If you aren't very opposed to the idea of having struct stmmac_fpe_ops
> contain a mix of function pointers and integer constants, I would
> suggest removing:
> 
> 	.fpe_configure()
> 	.fpe_send_mpacket()
> 	.fpe_irq_status()
> 	.fpe_get_add_frag_size()
> 	.fpe_set_add_frag_size()
> 
> and just keeping a single function pointer, .fpe_map_preemption_class(),
> inside stmmac_fpe_ops. Only that is sufficiently different to warrant a
> completely separate implementation. Then move all current struct
> stmmac_fpe_configure_info to struct stmmac_fpe_ops, and reimplement
> stmmac_fpe_configure() directly like common_fpe_configure(),
> stmmac_fpe_send_mpacket() directly like common_fpe_send_mpacket(), etc etc.
> This lets us avoid the antipattern of calling a function pointer (hidden
> by an opaque macro) from common code, only to gather some parameters to
> call again a common implementation.
> 
> I know this is a preposterous and heretic thing to suggest, but a person
> who isn't knee-deep in stmmac has a very hard time locating himself in
> space due to the unnecessarily complex layering. If that isn't something
> that is important, feel free to ignore.

In fact, I can drop the stmmac_fpe_ops at all, avoid the antipattern of
calling a function pointer for good.
Since this is a new module, we can try something new ;)
Thanks.