All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: David Howells <dhowells@redhat.com>,
	torvalds@osdl.org, akpm@osdl.org, davem@davemloft.net,
	matthew@wil.cx, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment
Date: Tue, 12 Dec 2006 23:17:22 +0000	[thread overview]
Message-ID: <3306.1165965442@redhat.com> (raw)
In-Reply-To: <20061212225443.GA25902@flint.arm.linux.org.uk>


Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
> 
> Why can't we just use atomic_t for this?

atomic_t is the wrong thing as it's basically an int, not an unsigned long.

atomic64_t/atomic_long_t is also probably the wrong thing to use as it's a
signed long (and the long is also volatile on some platforms - x86_64 for
example).  Bitops operate on unsigned long.

But the most important point is that assign_bits() has to take the same pointer
type as test_bit(), set_bit(), test_and_set_bit(), etc., and none of those
operate on an atomic*_t.

We could change that, of course, but I don't fancy tackling the task just at
the moment.  It oughtn't to be a difficult change, but there are a lot of flags
words in the kernel.

David

  parent reply	other threads:[~2006-12-12 23:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12 20:11 [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment David Howells
2006-12-12 20:11 ` [PATCH 2/2] WorkStruct: Use bitops-safe direct assignment David Howells
2006-12-12 22:54 ` [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment Russell King
2006-12-12 23:03   ` Paul Mackerras
2006-12-12 23:17   ` David Howells [this message]
2006-12-13  1:36   ` Linus Torvalds
2006-12-13  2:07     ` Nick Piggin
2006-12-13  2:30       ` Linus Torvalds
2006-12-15 22:45       ` Linus Torvalds
2006-12-18  8:56         ` David Woodhouse
2006-12-18  9:05           ` Evgeniy Polyakov
2006-12-18  9:10           ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3306.1165965442@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.