[Top] [All Lists]

Re: Re: Re: [PATCHv5] atomic: add *_dec_not_zero

To: Benjamin Herrenschmidt <>
Subject: Re: Re: Re: [PATCHv5] atomic: add *_dec_not_zero
From: Sven Eckelmann <>
Date: Mon, 05 Dec 2011 08:57:27 +0100
Cc: Russell King - ARM Linux <>,,,,, "H. Peter Anvin" <>, Heiko Carstens <>, Randy Dunlap <>, Paul Mackerras <>, Helge Deller <>,,,,,, Richard Weinberger <>, Hirokazu Takata <>,, "James E.J. Bottomley" <>, Ingo Molnar <>, Matt Turner <>, Fenghua Yu <>, Arnd Bergma nn <>, Jeff Dike <>, Chris Metcalf <>,, Ivan Kokshaysky <>, Thomas Gleixner <>,, Richard Henderson <>, Tony Luck <>,,,, Ralf Baechle <>, Kyle McMartin <>,, Martin Schwidefsky <>,, Andrew Morton <>,, "David S. Miller" <>
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1323071957; bh=WePDqzBwJCP0hF2CSPHbcjn+dXDe7R1+UWj3jvcP9G8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YLhX+3v2w/adgdJYo1WmVJXz+V/tTXwaYeuoK1R0np6NA/cIqn0rcMrC6N2J0TwiJ xaLo7SM19N/C9LE8VBq9pO+FWZhy621FtR4czTVA0FSt772SkwhixuzNJzTqkPR4RS 2sZhWGw2Dqq442a5TkoI9jRYd53Qjqf+HGJe/Y7o=
In-reply-to: <1323038515.11728.26.camel@pasglop>
References: <> <> <1323038515.11728.26.camel@pasglop>
User-agent: KMail/4.6.0 (Linux/3.1.0-1-686-pae; KDE/4.6.5; i686; ; )
On Monday 05 December 2011 09:41:55 Benjamin Herrenschmidt wrote:
> On Sun, 2011-12-04 at 22:18 +0000, Russell King - ARM Linux wrote:
>  .../...
> > And really, I believe it would be a good cleanup if all the standard
> > definitions for atomic64 ops (like atomic64_add_negative) were also
> > defined in include/linux/atomic.h rather than individually in every
> > atomic*.h header throughout the kernel source, except where an arch
> > wants to explicitly override it.  Yet again, virtually all architectures
> > define these in exactly the same way.
> > 
> > We have more than enough code in arch/ for any architecture to worry
> > about, we don't need schemes to add more when there's simple and
> > practical solutions to avoiding doing so if the right design were
> > chosen (preferably from the outset.)
> > 
> > So, I'm not going to offer my ack for a change which I don't believe
> > is the correct approach.
> I agree with Russell, his approach is a lot easier to maintain long run,
> we should even consider converting existing definitions.

I would rather go with "the existing definitions have to converted" and this 
means "not by this patch". At the moment, the atomic64 stuff exist only as 
separate generic or arch specific implementation. It is fine that Russell King 
noticed that people like Arun Sharma did a lot of work to made it true for 
atomic_t, but atomic64_t is a little bit different right now (at least as I 
understand it).

Kind regards,

Attachment: signature.asc
Description: This is a digitally signed message part.

<Prev in Thread] Current Thread [Next in Thread>