[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6a7ca69-2f65-5bf4-edbd-2644a1f3f124@rasmusvillemoes.dk>
Date: Thu, 21 Nov 2019 09:55:31 +0100
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: can we get rid of the cpumask_t typedef?
The cpumask_t alias for "struct cpumask" doesn't seem to qualify for the
kernel's requirement for when a typedef is warranted. It's also somewhat
easily confused with cpumask_var_t which has very good reasons for being
a typedef. "struct cpumask" outnumbers "cpumask_t" about 5:2.
The motivation for this is that kbuild informed me about some driver
that I just enabled for ARM happens to include asm/irq.h, and for magic
reasons no other previous header happens to pull in cpumask.h. So the
build fails
>> arch/arm/include/asm/irq.h:34:50: error: unknown type name 'cpumask_t'
extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask,
So I could just add a include linux/cpumask.h (and the reason I hadn't
noticed is that the -rt tree which I build upon carries just that) and
be done with it. But I'd rather not contribute to the "every header
pulls in every other header" madness. So I'd rather just change the
function to take a "struct cpumask *" and precede it with a forward
declaration of that.
As it happens, arch_trigger_cpumask_backtrace is a good example of the
sillyness the cpumask_t typedef leads to. ARM and Powerpc are
consistent, using cpumask_t in both declaration and definition. MIPS,
Sparc and x86 use "struct cpumask" in the declaration and cpumask_t in
the definition.
Rasmus
Powered by blists - more mailing lists