qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] clean build: Add bt-host.h


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] clean build: Add bt-host.h
Date: Wed, 11 Mar 2009 10:02:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

andrzej zaborowski wrote:
> 2009/3/8 Jan Kiszka <address@hidden>:
>> Aurelien Jarno wrote:
>>> On Sun, Mar 08, 2009 at 03:56:12PM +0100, Jan Kiszka wrote:
>>>> Jan Kiszka wrote:
>>>>> Silence compiler warning by providing a prototype in the CONFIG_BLUEZ
>>>>> case (hw/bt.h provides it otherwise).
>>>>>
>>>>> Signed-off-by: Jan Kiszka <address@hidden>
>>>>> ---
>>>>>
>>>>>  bt-host.c |    2 ++
>>>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/bt-host.c b/bt-host.c
>>>>> index 07679f6..066757a 100644
>>>>> --- a/bt-host.c
>>>>> +++ b/bt-host.c
>>>>> @@ -31,6 +31,8 @@
>>>>>  #  include <bluetooth/bluetooth.h>
>>>>>  #  include <bluetooth/hci.h>
>>>>>  #  include <bluetooth/hci_lib.h>
>>>>> +/* Silence compiler warning */
>>>>> +struct HCIInfo *bt_host_hci(const char *id);
>>>>>  # else
>>>>>  #  include "hw/bt.h"
>>>>>  #  define HCI_MAX_FRAME_SIZE       1028
>>>> Thanks for applying the other patches, but this tiny one always seems to
>>>> be ignored - for unknown reasons. :)
>>>>
>>> On my side, I consider that a hack, not a fix. We should make sure the
>>> correct header is included so that this function is declared.
>>>
>> As always: no comment means no progress. This one better?
> 
> 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.  I 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. 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". IMHO, virtio is cleanly
organized (and is surely no relevant contributor to compile times).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]