Re: [PATCH 1/2] irq_flags_t: intro and core annotations
[Posted October 23, 2007 by corbet]
| From: |
| Andrew Morton <akpm-AT-linux-foundation.org> |
| To: |
| Ralf Baechle <ralf-AT-linux-mips.org> |
| Subject: |
| Re: [PATCH 1/2] irq_flags_t: intro and core annotations |
| Date: |
| Mon, 22 Oct 2007 11:21:10 -0700 |
| Message-ID: |
| <20071022112110.105b8e11.akpm@linux-foundation.org> |
| Cc: |
| Alexey Dobriyan <adobriyan-AT-gmail.com>,
Al Viro <viro-AT-ftp.linux.org.uk>, torvalds-AT-linux-foundation.org,
viro-AT-zeniv.linux.org.uk, linux-kernel-AT-vger.kernel.org,
linux-arch-AT-vger.kernel.org |
| Archive‑link: | |
Article |
On Mon, 22 Oct 2007 16:29:12 +0100 Ralf Baechle <ralf@linux-mips.org> wrote:
> On Sun, Oct 21, 2007 at 01:30:42PM +0400, Alexey Dobriyan wrote:
>
> > irq_flags_t
> >
> > New type for use with spin_lock_irqsave() and friends.
>
> Talking about it, why did we ever require this to be a long anyway? I could
> get away with a single bit for MIPS; the rest of this variable is pure
> bloat. An abstract datatype could help finally fix this.
>
Yes, it's always been ugly that we use unsigned long for this rather than
abstracting it properly.
However I'd prefer that we have some really good reason for introducing
irq_flags_t now. Simply so that I don't needlessly spend the next two
years wrestling with literally thousands of convert-to-irq_flags_t patches
and having to type "please use irq_flags_t here" in hundreds of patch
reviews. (snivel, wimper)
