From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [v7][RFC][PATCH 04/13] hvmloader/util: get reserved
 device memory maps
Date: Tue, 28 Oct 2014 13:21:01 +0800
Message-ID: <544F27BD.7060003@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-5-git-send-email-tiejun.chen@intel.com>
	<544A7CCB0200007800041FBA@mail.emea.novell.com>
	<544DB809.9020108@intel.com>
	<544E22410200007800042568@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <544E22410200007800042568@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 2014/10/27 17:45, Jan Beulich wrote:
>>>> On 27.10.14 at 04:12, <tiejun.chen@intel.com> wrote:
>> On 2014/10/24 22:22, Jan Beulich wrote:
>>>>>> On 24.10.14 at 09:34, <tiejun.chen@intel.com> wrote:
>>>> --- a/tools/firmware/hvmloader/util.h
>>>> +++ b/tools/firmware/hvmloader/util.h
>>>> @@ -241,6 +241,12 @@ int build_e820_table(struct e820entry *e820,
>>>>                         unsigned int bios_image_base);
>>>>    void dump_e820_table(struct e820entry *e820, unsigned int nr);
>>>>
>>>> +#include <xen/memory.h>
>>>> +#define ENOBUFS     105 /* No buffer space available */
>>>
>>> This is a joke I hope? The #include belongs at the top (albeit afaict
>>> you don't really need it here), and the #define is completely
>>
>> If without this line, #include <xen/memory.h>,
>>
>> In file included from build.c:25:0:
>> ../util.h:246:70: error: array type has incomplete element type
>>    int get_reserved_device_memory_map(struct xen_reserved_device_memory
>> entries[],
>>                                                                         ^
>> make[8]: *** [build.o] Error 1
>
> So just forward declare the structure ahead of the function
> declaration.

tools/firmware/hvmloader/pci.c:28:#include <xen/memory.h>
tools/firmware/hvmloader/ovmf.c:36:#include <xen/memory.h>

So any reason I can't do such a same thing?

>
>>> misplaced here. While I generally wouldn't recommend doing this, I
>>> think in the case here including the hypervisor header that defines
>>> them would be okay. Perhaps not via relative path, but via having
>>
>> Seems we just need to include this,
>>
>> #include <errno.h>
>
> You shouldn't include system headers here - what if the build system's
> -E... values differ from Xen's? Please remember that what your making

tools/firmware/hvmloader/xenbus.c:30:#include <errno.h>

And why will Xen define this different?

Thanks
Tiejun

> changes to is not arbitrary application code.
>
> Jan
>
>
>