Date: Thu, 30 Mar 2006 17:40:22 -0800 (PST)
From: Christoph Lameter <clameter@sgi.com>
To: linux@horizon.com
cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Synchronizing Bit operations V2
In-Reply-To: <20060331013346.913.qmail@science.horizon.com>
Message-ID: <Pine.LNX.4.64.0603301738190.2758@schroedinger.engr.sgi.com>
References: <20060331013346.913.qmail@science.horizon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1313
Lines: 33

On Thu, 30 Mar 2006, linux@horizon.com wrote:

> The only conceivable reason for passing the mode as a separate parameter is
> - To change the mode dynamically at run time.
> - To share common code when the sequence is long and mostly shared
>   between the various modes (as in open(2) or ll_rw_block()).

There is usually quite complex code involved although the code generated 
is minimal.

> On the downside, it's more typing and uglier than a series of
> 
> frob_bit_nonatomic()
> 	(probably temporarily or permanently aliased to frob_bit())
> frob_bit_atomic()
> frob_bit_acquire()
> frob_bit_release()
> frob_bit_barrier()
> 
> functions, and those also prevent you from doing something silly like
> frob_bit(x, y, O_DIRECT).  Also, the MODE_ prefix might be wanted by
> something else.

Ok. We could change the MODE_ prefix but the problem with not passing this 
as a parameter that there are numerous functions derived from bit ops that 
are then also needed in lots of different flavors. Passing a parameter 
cuts down the number of variations dramatically.

-
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/