All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: Keir,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Fraser <Keir.Fraser@eu.citrix.com>
Subject: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET
Date: Wed, 30 Jun 2010 16:28:43 +0100	[thread overview]
Message-ID: <4C2B62AB.3020006@eu.citrix.com> (raw)
In-Reply-To: <4C2B7BC60200007800008DFF@vpn.id2.novell.com>

Jan Beulich wrote:
> That part your patch doesn't address either - rather than
> sizeof(uint16_t) as the first part of the expression you'd need to
> use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset).
>   
I was assuming that when someone changed struct t_info that they'd 
modify this macro as well; I suppose then that the two complaints are 
really different aspects of the same one -- that it might not be clear 
to the person who adjusts struct t_info how to translate those changes 
into T_INFO_FIRST_OFFSET.  I think this way is more clear.

I suppose even better might be to calculate 
t_info.mfn_mfn_offset[NR_CPUS] (or perhaps ...[num_possible_cpus]).  
Hmm... let me see what I can come up with.
> Btw., didn't we agree that public headers shouldn't make use of
> language extensions? struct t_info uses a variable sized array,
> which is an extension (standard only in C99).
>   
I'm not an expert in this.  It's lot more hassle to lay out the data the 
way I'd like without it.  I'll defer judgment to Keir.

 -George

  reply	other threads:[~2010-06-30 15:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29 15:32 [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET Jan Beulich
2010-06-30 14:52 ` George Dunlap
2010-06-30 15:15   ` Jan Beulich
2010-06-30 15:28     ` George Dunlap [this message]
2010-06-30 16:10       ` George Dunlap
2010-06-30 16:12         ` George Dunlap
2010-06-30 17:14           ` Keir Fraser
2010-06-30 18:12             ` George Dunlap
2010-07-01  9:50               ` Jan Beulich
2010-07-01  9:49           ` Jan Beulich
2010-07-01  9:53             ` George Dunlap

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=4C2B62AB.3020006@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@novell.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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 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.