| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20071022112110.105b8e11.akpm@linux-foundation.org> Date: Mon, 22 Oct 2007 11:21:10 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Ralf Baechle <ralf@...ux-mips.org> Cc: Alexey Dobriyan <adobriyan@...il.com>, Al Viro <viro@....linux.org.uk>, torvalds@...ux-foundation.org, viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org Subject: Re: [PATCH 1/2] irq_flags_t: intro and core annotations On Mon, 22 Oct 2007 16:29:12 +0100 Ralf Baechle <ralf@...ux-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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists