From: Andrew Morton <akpm@linux-foundation.org>
To: Dean Nelson <dcn@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Patch 03/18] define BYTES_PER_WORD
Date: Sun, 8 Jun 2008 17:12:35 -0700 [thread overview]
Message-ID: <20080608171235.5e1bba29.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080606164455.GD13695@sgi.com>
On Fri, 6 Jun 2008 11:44:55 -0500 Dean Nelson <dcn@sgi.com> wrote:
> Add a BYTES_PER_WORD #define.
>
> Signed-off-by: Dean Nelson <dcn@sgi.com>
>
> ---
>
> drivers/misc/sgi-xp/xp.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux-2.6/drivers/misc/sgi-xp/xp.h
> ===================================================================
> --- linux-2.6.orig/drivers/misc/sgi-xp/xp.h 2008-05-30 13:59:29.580809165 -0500
> +++ linux-2.6/drivers/misc/sgi-xp/xp.h 2008-05-30 14:00:00.200614111 -0500
> @@ -19,6 +19,9 @@
> #include <asm/sn/types.h>
> #include <asm/sn/bte.h>
>
> +/* >>> Add this #define to some linux header file some day. */
The patches fill the code with this ">>>" string - which can cause
false positives when people are searching for git rejects. Although I
(and I suspect most other people) search for "<<<<<<<".
> +#define BYTES_PER_WORD sizeof(void *)
Dunno if this is a desirable thing to have, really. A "word" is a
somewhat ill-defined thing. The definition you have here is always
equal to BYTES_PER_LONG. If BYTES_PER_LONG is inappropriate then
BYTES_PER_POINTER would be clearer.
next prev parent reply other threads:[~2008-06-09 0:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-06 16:40 [Patch 00/18] continued prepartion of XPC/XPNET to support SGI UV Dean Nelson
2008-06-06 16:42 ` [Patch 01/18] define is_shub() and is_uv() macros Dean Nelson
2008-06-06 16:43 ` [Patch 02/18] define xpSalError reason code Dean Nelson
2008-06-06 16:44 ` [Patch 03/18] define BYTES_PER_WORD Dean Nelson
2008-06-09 0:12 ` Andrew Morton [this message]
2008-06-06 16:46 ` [Patch 04/18] support runtime selection of xp_max_npartitions Dean Nelson
2008-06-06 16:47 ` [Patch 05/18] create a common xp_remote_memcpy() function Dean Nelson
2008-06-06 16:48 ` [Patch 06/18] prepare xpc_rsvd_page to work on either sn2 or uv hardware Dean Nelson
2008-06-06 16:49 ` [Patch 07/18] isolate xpc_vars_part structure to sn2 only Dean Nelson
2008-06-06 16:51 ` [Patch 08/18] isolate xpc_vars " Dean Nelson
2008-06-06 16:52 ` [Patch 09/18] base xpc_rsvd_page's timestamp on jiffies Dean Nelson
2008-06-09 0:15 ` Andrew Morton
2008-06-06 16:53 ` [Patch 10/18] move xpc_allocate() into xpc_send()/xpc_send_notify() Dean Nelson
2008-06-06 16:54 ` [Patch 11/18] isolate activate IRQ's hardware specific components Dean Nelson
2008-06-06 16:55 ` [Patch 12/18] isolate additional sn2 specific code Dean Nelson
2008-06-06 16:56 ` [Patch 13/18] separate chctl_flags from XPC's notify IRQ Dean Nelson
2008-06-06 16:58 ` [Patch 14/18] replace AMO_t typedef by struct amo Dean Nelson
2008-06-06 16:59 ` [Patch 15/18] isolate allocation of XPC's msgqueues to sn2 only Dean Nelson
2008-06-06 17:00 ` [Patch 16/18] enable XPNET to handle more than 64 partitions Dean Nelson
2008-06-06 17:02 ` [Patch 17/18] isolate remote copy buffer to sn2 only Dean Nelson
2008-06-06 17:03 ` [Patch 18/18] add _sn2 suffix to a few variables Dean Nelson
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=20080608171235.5e1bba29.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dcn@sgi.com \
--cc=linux-kernel@vger.kernel.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.