From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 2/2 V2] kvm tools: Fix virt_queue__set_used_elem
Date: Thu, 5 May 2011 09:47:16 +0200
Message-ID: <20110505074716.GC14391@elte.hu>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Asias He <asias.hejun@gmail.com>,
	Sasha Levin <levinsasha928@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 mx2.mail.elte.hu ([157.181.151.9]:40552 "EHLO mx2.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752465Ab1EEHrW (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 5 May 2011 03:47:22 -0400
Content-Disposition: inline
In-Reply-To: <BANLkTikU76tDjdEBdXFTJvm-aH45oFGqkw@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Pekka Enberg <penberg@kernel.org> wrote:

> On Thu, May 5, 2011 at 10:02 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Asias He <asias.hejun@gmail.com> wrote:
> >
> >> With commit d7f0c07afeefa2d20739437306e4b8bb2853cf83 in master
> >> (kvm tools: Fix virt_queue__set_used_elem)
> >>
> >> I see this:
> >>
> >> asias@hj:~/qemu-stuff/pekka.git/tools/kvm$ make
> >> =A0 GEN =A0 =A0 =A0include/common-cmds.h
> >> ../../include/asm-generic/bitops/fls64.h:33:2: error: #error
> >> BITS_PER_LONG not 32 or 64
> >
> > The build fails here too, in a similar way, on a 32-bit Fedora 14 b=
ox.
>=20
> 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=20
assymetric requirements on 64-bit and 32-bit systems.

We could fix it (provide those dependencies), or we could pick=20
tools/perf/perf.h's mb() definitions. That's much cruder than the nice =
kernel=20
memory barriers though ...

Thanks,

	Ingo