From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ugh9G-0006bK-Lw for qemu-devel@nongnu.org; Sun, 26 May 2013 16:02:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ugh9D-0000VM-VW for qemu-devel@nongnu.org; Sun, 26 May 2013 16:02:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ugh9D-0000VI-O5 for qemu-devel@nongnu.org; Sun, 26 May 2013 16:02:31 -0400 Date: Sun, 26 May 2013 23:02:51 +0300 From: "Michael S. Tsirkin" Message-ID: <20130526200251.GA4305@redhat.com> References: <1369581694-1655-1-git-send-email-mst@redhat.com> <20130526175110.GA3115@redhat.com> <20130526181017.GB3115@redhat.com> <51A253C6.7060303@redhat.com> <20130526183747.GB3427@redhat.com> <51A25A2D.8030700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A25A2D.8030700@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , qemu-devel@nongnu.org On Sun, May 26, 2013 at 08:53:33PM +0200, Paolo Bonzini wrote: > Il 26/05/2013 20:37, Michael S. Tsirkin ha scritto: > >> > I don't like defining __-prefixed types. Can we preprocess > >> > linux-headers to avoid usage of __u8/16/32/64, and to > >> > s,linux/types.h,stdint.h, ? > >> > > >> > Paolo > > Let's not be purists, and do the practical thing. > > > > When I suggested this you didn't like it: > >>> >> I can think of two ways: > >>> >> - strip linux/types.h in update_headers > >>> >> - add a stub linux/types.h for non linux platforms > >> > > >> >The latter, using stdint.h types, would be fine. > > My fault. I should have looked at linux/types.h (actually asm-generic/). > > Paolo Not really, __uX appear in the headers that were posted. What I'm saying is - a chance of a conflict is very remote, if it happens it's a build failure so easy to debug. -- MST