[PATCH 1/2] args.h: add more helpers for manipulating macro arguments
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Thu May 2 10:17:26 UTC 2024
On Thu, May 02, 2024 at 11:49:16AM +0200, Michal Wajdeczko wrote:
>
>
> On 02.05.2024 09:27, Andy Shevchenko wrote:
> > On Thu, May 02, 2024 at 12:32:20AM +0200, Michal Wajdeczko wrote:
> >> Some advanced macros used to generate code may use helper macros
> >> to manipulate the argument lists. Define generic helpers that can
> >> replace existing local definitions and allow reuse by new code.
> >
> > Acked-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> >
> > In general I have no objections, but as I pointed out in the reply to cover
> > letter the statistics is a bit scary, i.e. we add too many lines without clear
>
> with another spotted potential user (macro FIRST from bpf_probe.h) and
> without comments those statistics will look like:
>
> drivers/gpu/drm/xe/xe_rtp.h | 4 ++--
> drivers/gpu/drm/xe/xe_rtp_helpers.h | 26 ++++++++++----------------
> include/linux/args.h | 26 ++++++++++++++++++++++++++
> include/trace/bpf_probe.h | 7 ++-----
> 4 files changed, 40 insertions(+), 23 deletions(-)
Still not convincing, I would suggest to have xe_args.h for now. You may put
a comment that if new users will come, these macros may be moved to args.h.
> > benefit. Anyway, if people okay with that my tag is above (but also pay
> > attention that args.h is used in dozen of cases, including headers, right now
> > and this extension may affect a lot the build time of the kernel).
>
> not an expert here, but I guess the cost of parsing another dozen of
> lines should negligible compared with opening hundreds of other include
> files during compilation ...
--
With Best Regards,
Andy Shevchenko
More information about the Intel-xe
mailing list