From: Yajun Deng <yajun.deng@xxxxxxxxx>
Date: Wed, 13 Sep 2023 10:08:08 +0800
On 2023/9/13 00:22, Alexander Lobakin wrote:[...]
From: Yajun Deng <yajun.deng@xxxxxxxxx>
Date: Mon, 11 Sep 2023 16:20:16 +0800
Ah I see. BTW, if you will still define increment functions asEXPORT_SYMBOL_GPL(dev_core_stats_inc); // Why not GPL BTW?This may be a better option.
Just because EXPORT_SYMBOL(netdev_core_stats_alloc) before, but I think
EXPORT_SYMBOL_GPL is better.
externals, there will be no reason to export netdev_core_stats_alloc()
or even make it non-static at all.
By "the former" you mean to build static inlines or externals? SeemsAnd then build inlines:I would like the former. Keep it the same as before.
#define DEV_CORE_STATS_INC(FIELD) \
static inline void \
dev_core_stats_##FIELD##_inc(struct net_device *dev) \
{ \
dev_core_stats_inc(dev, \
offsetof(struct net_device_core_stats, FIELD)); \
}
DEV_CORE_STATS_INC(rx_dropped);
...
OR even just make them macros
#define __DEV_CORE_STATS_INC(dev, field) \
dev_core_stats_inc(dev, \
offsetof(struct net_device_core_stats, field))
#define dev_core_stats_rx_dropped_inc(dev) \
__DEV_CORE_STATS_INC(dev, rx_dropped)
...
like the first one, but I got confused by your "the same as before" :D
Ok, after this one I guess you meant "I'd like to use your approach with
Just don't copy that awful Thunderbird's line wrap and don't assume thisI agree that.
code builds and works and that is something finished/polished.
You'll be able to trace functions and you'll be able to understand which
counter has been incremented by checking the second argument, i.e. the
field offset (IIRC tracing shows you arguments).
And that way you wouldn't geometrically increase the number of symbol
exports and deal with its consequences.
static inlines".
Thanks,/**Thanks,
* dev_get_stats - get network device statistics
Olek
Olek