From: "H. Peter Anvin" <hpa@zytor.com>
To: Glauber de Oliveira Costa <glommer@gmail.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Glauber de Oliveira Costa <gcosta@redhat.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
tglx@linutronix.de, mingo@elte.hu, ehabkost@redhat.com,
jeremy@goop.org, avi@qumranet.com, anthony@codemonkey.ws,
virtualization@lists.linux-foundation.org, ak@suse.de,
chrisw@sous-sol.org, rostedt@goodmis.org, zach@vmware.com,
roland@redhat.com
Subject: Re: [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter.
Date: Tue, 18 Dec 2007 09:26:35 -0800 [thread overview]
Message-ID: <476802CB.5050503@zytor.com> (raw)
In-Reply-To: <5d6222a80712180440l72faa8fere9588ea6894cf1cb@mail.gmail.com>
Glauber de Oliveira Costa wrote:
> On Dec 18, 2007 3:18 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote:
>>> This patch changes the bitwise operations in bitops.h to get
>>> a void pointers as a parameter. Before this patch, a lot of warnings
>>> can be seen. They're gone after it.
>> No, this is a backwards step! These warnings are important for
>> non-arch-specific code: I fought hard to get them made into unsigned longs.
>>
>> But I'm happy for this to be applied as is, then I'll grab the git tree,
>> revert it and fix the warnings...
>>
> Even before my processor.h patches, there are a lot of warnings caused by this.
> If Ingo does not mind getting more warnings, I can drop this patch
> entirely, and you (or someone else)
> can fix them later on.
For any code that can be executed on a bigendian processor, those are
real bugs. For littleendian-only code they're arguably nuisance
warnings, but still...
-hpa
next prev parent reply other threads:[~2007-12-18 17:34 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-17 22:52 [PATCH 0/21] Integrate processor.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 1/21] move tsc definitions to were they belong Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 2/21] [PATCH] get rid of _MASK flags Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 3/21] [PATCH] move desc_empty to where they belong Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 4/21] [PATCH] move load_cr3 to a common place Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 5/21] [PATCH] unify paravirt pieces of processor.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 6/21] [PATCH] move the definition of set_iopl_mask to common header Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 7/21] [PATCH] unify common parts of processor.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 8/21] [PATCH] unify current_text_addr Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 9/21] [PATCH] unify tss_struct Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 10/21] [PATCH] provide x86_64 with a load_sp0 function Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 11/21] [PATCH] unify thread struct Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 12/21] [PATCH] unify TASK_ALIGN definitions Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 14/21] [PATCH] unify x86_cpuinfo struct Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 15/21] [PATCH] remove legacy stuff from processor_64.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 16/21] [PATCH] unify mm_segment_t definition Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 17/21] [PATCH] move definitions to processor.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 18/21] [PATCH] unify prefetch operations Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 19/21] [PATCH] unify asm nops Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 20/21] [PATCH] move i387 definitions to processor.h Glauber de Oliveira Costa
2007-12-17 22:52 ` [PATCH 21/21] [PATCH] finish processor.h integration Glauber de Oliveira Costa
2007-12-18 13:19 ` Ingo Molnar
2007-12-18 13:38 ` Ingo Molnar
2007-12-18 13:40 ` Ingo Molnar
2007-12-18 13:49 ` Glauber de Oliveira Costa
2007-12-18 15:44 ` Ingo Molnar
2007-12-18 13:48 ` Glauber de Oliveira Costa
2007-12-18 15:43 ` Ingo Molnar
2007-12-18 5:18 ` [PATCH 13/21] [PATCH] change bitwise operations to get a void parameter Rusty Russell
2007-12-18 5:38 ` H. Peter Anvin
2007-12-18 12:40 ` Glauber de Oliveira Costa
2007-12-18 17:26 ` H. Peter Anvin [this message]
2007-12-18 11:45 ` [PATCH 7/21] [PATCH] unify common parts of processor.h Ingo Molnar
2007-12-18 12:05 ` Glauber de Oliveira Costa
2007-12-18 14:00 ` Ingo Molnar
2007-12-18 5:14 ` [PATCH 3/21] [PATCH] move desc_empty to where they belong Rusty Russell
2007-12-18 5:35 ` Roland McGrath
2007-12-18 5:50 ` Roland McGrath
2007-12-18 5:59 ` [PATCH x86/mm] x86: TLS desc_struct cleanup Roland McGrath
2007-12-18 12:03 ` [PATCH 3/21] [PATCH] move desc_empty to where they belong Glauber de Oliveira Costa
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=476802CB.5050503@zytor.com \
--to=hpa@zytor.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=anthony@codemonkey.ws \
--cc=avi@qumranet.com \
--cc=chrisw@sous-sol.org \
--cc=ehabkost@redhat.com \
--cc=gcosta@redhat.com \
--cc=glommer@gmail.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=zach@vmware.com \
/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