Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <d6a7ca69-2f65-5bf4-edbd-2644a1f3f124@rasmusvillemoes.dk>
In-Reply-To: <d6a7ca69-2f65-5bf4-edbd-2644a1f3f124@rasmusvillemoes.dk>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 21 Nov 2019 16:04:58 -0800
Message-ID: <CAHk-=wgf+qpDY31ojxqPdkSHT6f+E9yGM_L16iNhv9owEpbx7Q@mail.gmail.com>
Subject: Re: can we get rid of the cpumask_t typedef?
To:     Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 21, 2019 at 12:55 AM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> 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,

Yes. Please just add a forward declaration of 'struct cpumask', and
change that cpumask_t to use that instead.

I'm not sure we need to remove it entirely (there's a fair number of
users), but we can/should deprecate it, and certainly use 'struct
cpumask' in function declarations etc so that you don't need to go
through some include file hell.

           Linus