From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [PATCH 2/2 V2] kvm tools: Fix virt_queue__set_used_elem
Date: Thu, 05 May 2011 11:01:33 +0300
Message-ID: <1304582493.9537.5.camel@lappy>
References: <1304454487-2539-1-git-send-email-levinsasha928@gmail.com>
	 <1304454487-2539-2-git-send-email-levinsasha928@gmail.com>
	 <20110503204716.GA27887@elte.hu> <1304484063.13143.9.camel@lappy>
	 <4DC1E57B.3060809@gmail.com> <20110505070211.GA13043@elte.hu>
	 <BANLkTikU76tDjdEBdXFTJvm-aH45oFGqkw@mail.gmail.com>
	 <20110505074716.GC14391@elte.hu>
	 <BANLkTi=Lg7K-hXBKRCFv48MkiKY_bwL2QA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Ingo Molnar <mingo@elte.hu>, Asias He <asias.hejun@gmail.com>,
	gorcunov@gmail.com, prasadjoshi124@gmail.com, kvm@vger.kernel.org
To: Pekka Enberg <penberg@kernel.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-ww0-f42.google.com ([74.125.82.42]:36289 "EHLO
	mail-ww0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752969Ab1EEIBn (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 5 May 2011 04:01:43 -0400
Received: by wwk4 with SMTP id 4so5043198wwk.1
        for <kvm@vger.kernel.org>; Thu, 05 May 2011 01:01:41 -0700 (PDT)
In-Reply-To: <BANLkTi=Lg7K-hXBKRCFv48MkiKY_bwL2QA@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, 2011-05-05 at 10:52 +0300, Pekka Enberg wrote:
> On Thu, May 5, 2011 at 10:47 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >> > The build fails here too, in a similar way, on a 32-bit Fedora 14 box.
> >>
> >> Curious. It works fine on my box. I think it's missing #include
> >> <asm/bitsperlong.h>. I wonder why system.h isn't pulling that
> >> itself...
> >
> > asm/system.h is one of the messier kernel headers, so i'm not surprised it has
> > assymetric requirements on 64-bit and 32-bit systems.
> 
> So does including <asm/bitsperlong.h> before <asm/system.h> fix the
> problem on 32-bit boxes? If so, I'd prefer we fix it like that for
> now.
> 
> > We could fix it (provide those dependencies), or we could pick
> > tools/perf/perf.h's mb() definitions. That's much cruder than the nice kernel
> > memory barriers though ...
> 
> That's the second best option, I think.

I agree with Pekka, For the same reasons we provided the dependencies
for including <linux/list.h> instead of just taking the source.

-- 

Sasha.