From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lkg4l-00080S-Vf for qemu-devel@nongnu.org; Fri, 20 Mar 2009 10:52:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lkg4h-000804-E5 for qemu-devel@nongnu.org; Fri, 20 Mar 2009 10:51:59 -0400 Received: from [199.232.76.173] (port=51424 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lkg4h-000801-6t for qemu-devel@nongnu.org; Fri, 20 Mar 2009 10:51:55 -0400 Received: from mail-bw0-f172.google.com ([209.85.218.172]:35482) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lkg4g-0000tG-Lj for qemu-devel@nongnu.org; Fri, 20 Mar 2009 10:51:54 -0400 Received: by bwz20 with SMTP id 20so832789bwz.34 for ; Fri, 20 Mar 2009 07:51:52 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <49B77E19.3010609@siemens.com> References: <20090221190054.12485.30486.stgit@mchn012c.ww002.siemens.net> <20090221190055.12485.61603.stgit@mchn012c.ww002.siemens.net> <49B3DC8C.6050700@web.de> <20090308184444.GT32521@hall.aurel32.net> <49B422DD.3080300@web.de> <49B77E19.3010609@siemens.com> Date: Fri, 20 Mar 2009 15:51:52 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH] clean build: Add bt-host.h From: andrzej zaborowski Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 2009/3/11 Jan Kiszka : > andrzej zaborowski wrote: ,,, >> Is it? >> struct HCIInfo is defined in net.h so maybe this one belongs there too. >> >> I'd much rather turn off the unhelpful warnings, some of them caused >> developers to add code that is both more hacky and slower. =C2=A0I also >> think we could save many header files like the hw/virtio-*.h, at this >> granularity they don't help with compile times which was the reason >> vl.h was split. > > I think we see so far a net gain from the warnings as several real bugs > were caught that way. Some of the warnings are useful and some are just "if leave your house a brick might fall on your head and you might die" type. > And in this case the warning pointed out unclean > header organization (internal API exports mixed up with generic > bluetooth types). The goal should not be "as few headers as possible" > but "one header per reasonably partitioned API". Right, this makes browsing the headers much easier when looking up a prototype. This change is in the opposite direction. (and why is it less hacky?) Cheers