[PATCH v3 1/3] drm/xe: Add helpers for manipulating macro arguments

Andy Shevchenko andriy.shevchenko at linux.intel.com
Mon May 6 13:59:43 UTC 2024


On Mon, May 06, 2024 at 03:17:32PM +0200, Michal Wajdeczko wrote:
> On 03.05.2024 17:59, Andy Shevchenko wrote:
> > On Fri, May 03, 2024 at 12:33:11AM +0200, Michal Wajdeczko wrote:

...

> >> +#define DROP_FIRST(args...)		__DROP_FIRST(args)
> >> +#define __DROP_FIRST(a, b...)		b
> > 
> >> +#define PICK_FIRST(args...)		__PICK_FIRST(args)
> >> +#define __PICK_FIRST(a, b...)		a
> > 
> >> +#define PICK_LAST(args...)		__PICK_ARG(COUNT_ARGS(args), args)
> > 
> > All but these have ARG(S) in the name, I would add it.
> 
> but then final names will be IMO little too long
> 
> 	DROP_FIRST_ARG
> 	PICK_FIRST_ARG
> 	PICK_LAST_ARG
> 
> maybe
> 	FIRST_ARG and LAST_ARG
> 
> would work still have no idea for the replacement for DROP_FIRST
> (and likely DROP/PICK FIRST will be more frequently used than LAST)

Works for me.

> besides, CONCATENATE also doesn't have ARGS in it's name

Yes, but it's not a good argument (pun is accidental).

> >> +#define __PICK_ARG(n, args...)		CALL_ARGS(CONCATENATE(PICK_ARG, n), args)
> > 
> > Interesting, why FIRST and LAST are not symmetrical. Maybe the first
> > counterpart can use the __PICK_ARG()?
> 
> the PICK_FIRST could be defined without introducing PICK_LAST combo
> 
> and PICK_LAST was initially considered less important (but still serves
> as a part of the complete solution) and it is implemented based on
> simpler (and more likely accepted) PICK_FIRST and DROP_FIRST macros
> 
> since series is now already merged to Xe,

How comes? I have not being notified. I assume we are still in the settling
down phase.

> I guess we can return to this
> discussion when we will be promoting these macros to linux/args.h

I would fix the namings right away, it will really help to avoid possible
and unneeded collisions.

-- 
With Best Regards,
Andy Shevchenko




More information about the Intel-xe mailing list