Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757973AbXJ0UcS (ORCPT ); Sat, 27 Oct 2007 16:32:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751386AbXJ0UcI (ORCPT ); Sat, 27 Oct 2007 16:32:08 -0400 Received: from sovereign.computergmbh.de ([85.214.69.204]:45279 "EHLO sovereign.computergmbh.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752663AbXJ0UcH (ORCPT ); Sat, 27 Oct 2007 16:32:07 -0400 Date: Sat, 27 Oct 2007 22:32:04 +0200 (CEST) From: Jan Engelhardt To: Alexey Dobriyan cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] irq_flags_t: intro and core annotations In-Reply-To: <20071027202449.GF9816@martell.zuzino.mipt.ru> Message-ID: References: <20071020235546.GB1825@martell.zuzino.mipt.ru> <20071027202449.GF9816@martell.zuzino.mipt.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 41 On Oct 28 2007 00:24, Alexey Dobriyan wrote: > >> (Which would be the logical choice if it were a function and not a >> macro...) That would flag up all violations ("without cast to different >> pointer" or so) while usually not breaking compilation. >> >> Of course, irq_flags_t is probably the best long-term solution if one >> wants to hide a struct. (Even then perhaps, use a pointer instead?) > >IIRC, Christoph mentioned: > > irq_flags_t flags; > > flags = spin_lock_irqXXX(&lock); > spin_unlock_irqYYY(&lock, flags); > >where XXX and YYY are still to be found good names :^) It's also a solution >without flag day and with more sane lock part -- "how flags are modified >if they are passed by value?" > >I start to like this proposal but I can't come up with good names. > The BSD way: just add a number -- spin_lock_irq2() Of course names are preferable. irq_spin_lock and irq_spin_unlock? spinirq_lock, spinirq_unlock? spin_lock_irq_disable, spin_lock_irq_enable (a bit verbose...) Maybe the 'irq' part should be completely dropped from the name, as with -rt extensions, it behaves differently, does not it? (Or was it preemption?) If it was a home project, I'd just flag it, if it was a business project, I'd add the number, for Linux - ha, too big for me :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/