Re: [Qemu-devel] [PATCH] xen: fix xen-mapcache build on non-Xen capable targets

[Stefan Weil <weil@mail.berlios.de>]

Am 20.07.2011 13:01, schrieb Stefano Stabellini:
> On Wed, 20 Jul 2011, Avi Kivity wrote:
>> Signed-off-by: Avi Kivity <avi@redhat.com>
>
> Alex sent another patch few days ago to do the same thing:
>
> http://marc.info/?l=qemu-devel&m=131099500331906&w=2
>
> it hasn't been merged yet but it is in Alex's xen-next branch.

So there are now at least 3 solutions (because I also
had prepared a patch which is still unpublished).

The last time I had sent a patch for the same problem with
conditionalcompilation (so no stubs were needed):
http://patchwork.ozlabs.org/patch/96204/.
Jan then proposed using static inline stub functions.

IMHO, static inline stub functions (Avi's patch) are
better than stub functions (Alex' patch) because they
avoid dead code for the stub functions. As far as I
know most linkers don't remove dead code.

In Avi's patch, there remain some questions:

* CONFIG_XEN needs config.h. Is it also included
   (indirectly) in xen-all.c? I don't know that up to now,
   that's the reason why I did not publish my patch.

* I only needed three inline stub functions:

static inline uint8_t *xen_map_cache(target_phys_addr_t phys_addr,
                                      target_phys_addr_t size, uint8_t lock)
{
     return NULL;
}

static inline ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
{
     return 0;
}

static void xen_invalidate_map_cache_entry(uint8_t *buffer)
{
}

* Do we need abort() and the related include statement?
   Maybe assert(!"unexpected function call") would be a better
   replacement for abort(), or simply do nothing.

No matter which solution is applied, I'd appreciate that
it is applied soon because the current builds are broken
for compilations without optimization.

Cheers,
Stefan Weil