From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET Date: Wed, 30 Jun 2010 16:28:43 +0100 Message-ID: <4C2B62AB.3020006@eu.citrix.com> References: <4C2A2E370200007800008A61@vpn.id2.novell.com> <4C2B7BC60200007800008DFF@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C2B7BC60200007800008DFF@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Keir, "xen-devel@lists.xensource.com" , Fraser List-Id: xen-devel@lists.xenproject.org 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