From: Arnd Bergmann <arnd@arndb.de>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: linux-arch@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org,
kvm-ia64@vger.kernel.org, fernando@oss.ntt.co.jp,
mtosatti@redhat.com, agraf@suse.de, kvm-ppc@vger.kernel.org,
linux-kernel@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp,
linuxppc-dev@ozlabs.org, mingo@redhat.com, paulus@samba.org,
Avi Kivity <avi@redhat.com>,
hpa@zytor.com, tglx@linutronix.de
Subject: Re: [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro
Date: Thu, 6 May 2010 15:38:54 +0200 [thread overview]
Message-ID: <201005061538.54326.arnd@arndb.de> (raw)
In-Reply-To: <20100505115924.7bb92036.takuya.yoshikawa@gmail.com>
On Wednesday 05 May 2010, Takuya Yoshikawa wrote:
> Date:
> Yesterday 04:59:24
> > That's why the bitmaps are defined as little endian u64 aligned, even on
> > big endian 32-bit systems. Little endian bitmaps are wordsize agnostic,
> > and u64 alignment ensures we can use long-sized bitops on mixed size
> > systems.
Ok, I see.
> There was a suggestion to propose set_le_bit_user() kind of macros.
> But what I thought was these have a constraint you two explained and seemed to be
> a little bit specific to some area, like KVM.
>
> So I decided to propose just the offset calculation macro.
I'm not sure I understand how this macro is going to be used though.
If you are just using this in kernel space, that's fine, please go for
it.
However, if the intention is to use the same macro in user space, putting
it into asm-generic/bitops/* is not going to help, because those headers
are not available in user space, and I wouldn't want to change that.
The definition of the macro is not part of the ABI, so just duplicate
it in KVM if you need it there.
Arnd
next prev parent reply other threads:[~2010-05-06 13:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 12:56 [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-04 12:58 ` [RFC][PATCH 1/12 applied today] KVM: x86: avoid unnecessary bitmap allocation when memslot is clean Takuya Yoshikawa
2010-05-04 13:00 ` [RFC][PATCH 2/12] KVM: introduce slot level dirty state management Takuya Yoshikawa
2010-05-04 13:01 ` [RFC][PATCH 3/12] KVM: introduce wrapper functions to create and destroy dirty bitmaps Takuya Yoshikawa
2010-05-04 13:02 ` [RFC][PATCH 4/12] x86: introduce copy_in_user() for 32-bit Takuya Yoshikawa
2010-05-04 13:02 ` [RFC][PATCH 5/12] x86: introduce __set_bit() like function for bitmaps in user space Takuya Yoshikawa
2010-05-04 13:03 ` [RFC][PATCH 6/12 not tested yet] PPC: introduce copy_in_user() for 32-bit Takuya Yoshikawa
2010-05-04 13:04 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space Takuya Yoshikawa
2010-05-11 16:00 ` Alexander Graf
2010-05-12 9:25 ` Takuya Yoshikawa
2010-05-04 13:05 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Takuya Yoshikawa
2010-05-04 15:03 ` Arnd Bergmann
2010-05-04 16:08 ` Avi Kivity
2010-05-05 2:59 ` Takuya Yoshikawa
2010-05-06 13:38 ` Arnd Bergmann [this message]
2010-05-10 11:46 ` Takuya Yoshikawa
2010-05-10 12:01 ` Avi Kivity
2010-05-10 12:01 ` Arnd Bergmann
2010-05-10 12:09 ` Takuya Yoshikawa
2010-05-04 13:06 ` [RFC][PATCH 9/12] KVM: introduce a wrapper function of set_bit_user_non_atomic() Takuya Yoshikawa
2010-05-04 13:07 ` [RFC][PATCH RFC 10/12] KVM: move dirty bitmaps to user space Takuya Yoshikawa
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-12 6:27 ` Takuya Yoshikawa
2010-05-04 13:08 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Takuya Yoshikawa
2010-05-11 3:43 ` Marcelo Tosatti
2010-05-11 5:53 ` Takuya Yoshikawa
2010-05-11 14:07 ` Marcelo Tosatti
2010-05-12 6:03 ` Takuya Yoshikawa
2010-05-04 13:11 ` [RFC][PATCH 12/12 sample] qemu-kvm: use " Takuya Yoshikawa
2010-05-10 12:06 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Avi Kivity
2010-05-10 12:26 ` Takuya Yoshikawa
2010-05-11 10:11 ` Takuya Yoshikawa
2010-05-13 11:47 ` Avi Kivity
2010-05-17 9:06 ` Takuya Yoshikawa
2010-05-11 15:55 ` Alexander Graf
2010-05-12 9:19 ` Takuya Yoshikawa
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=201005061538.54326.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=fernando@oss.ntt.co.jp \
--cc=hpa@zytor.com \
--cc=kvm-ia64@vger.kernel.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=paulus@samba.org \
--cc=takuya.yoshikawa@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).