[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3a11ef5-3e4e-0c4a-790b-63da94a1545c@gmail.com>
Date: Sat, 18 Jul 2020 14:53:27 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jiri Pirko <jiri@...lanox.com>,
Eric Dumazet <edumazet@...gle.com>,
Taehee Yoo <ap420073@...il.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Maxim Mikityanskiy <maximmi@...lanox.com>,
Richard Cochran <richardcochran@...il.com>,
Michal Kubecek <mkubecek@...e.cz>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 3/4] net: Call into DSA netdevice_ops wrappers
On 7/18/2020 2:18 PM, Vladimir Oltean wrote:
> On Fri, Jul 17, 2020 at 08:05:32PM -0700, Florian Fainelli wrote:
>> Make the core net_device code call into our ndo_do_ioctl() and
>> ndo_get_phys_port_name() functions via the wrappers defined previously
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>> ---
>> net/core/dev.c | 5 +++++
>> net/core/dev_ioctl.c | 5 +++++
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 062a00fdca9b..19f1abc26fcd 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -98,6 +98,7 @@
>> #include <net/busy_poll.h>
>> #include <linux/rtnetlink.h>
>> #include <linux/stat.h>
>> +#include <net/dsa.h>
>> #include <net/dst.h>
>> #include <net/dst_metadata.h>
>> #include <net/pkt_sched.h>
>> @@ -8602,6 +8603,10 @@ int dev_get_phys_port_name(struct net_device *dev,
>> const struct net_device_ops *ops = dev->netdev_ops;
>> int err;
>>
>> + err = dsa_ndo_get_phys_port_name(dev, name, len);
>
> Stupid question, but why must these be calls to an inline function whose
> name is derived through macro concatenation and hardcoded for 2
> arguments, then pass through an additional function pointer found in a
> DSA-specific lookup table, and why cannot DSA instead simply export
> these 2 symbols (with a static inline EOPNOTSUPP fallback), and simply
> provide the implementation inside those?
The macros could easily be changed to take a single argument list and
play tricks with arguments ordering etc. so I would decouple them from
the choice of using them.
If we have the core network stack reference DSA as a module then we
force DSA to be either built-in or not, which is not very practical,
people would still want a modular choice to be possible. The static
inline only wraps indirect function pointer calls using definitions
available at build time and actual function pointer substitution at run
time, so we avoid that problem entirely that way.
--
Florian
Powered by blists - more mailing lists