qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Date: Mon, 24 May 2010 17:20:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Juan Quintela <address@hidden> wrote:
> Hi

Paul, I intended to CC'd you on this series, just forgot at the last moment.

Sorry, Juan.

> This series:
> a- bring back the support for config-devices.h
>
>    Paul was the one that removed my previous submission.
>    You can see on the last patch why I want config-devices.h
>
> b- move all hpet code to hpet.c/hpet_emul.h
>
>    In the last patch, I add CONFIG_HPET define, and made everything
>    depending on that define.  When we have !CONFIG_HPET we just create
>    stub functions.
>
> This was my idea to create config-devices.h in the first place.
>
> Paul, if you don't like it, I am open to alternatives.  Problem here
> is that there are devices that we don't want to ship in RHEL for one
> reason or another.  Solutions so far:
>
> - use Makefile/ifdefs in calling files trickery: this is ugly as hell
>   and was refused (I sent patches to do that ~1 year ago).
>
> I was told to use CONFIG_FOO to disable the full compilation and a
> config file, like the kernel.
>
> Here we go, then Paul removed the config-device.h part, because:
>
>>   Also remove config-devices.h.  Code does not and should not care which
>>   devices are being built.
>
> This is ok, when device is only called through qdev, and then it is trivial
> to compile out.
>
> Notice that that there are another cases where we have to do Makefile tricks
> just because we don't have config-devices.mak symbols in "C-land".
>
> See for example Makefile.target
>
> CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y)
>
> obj-$(CONFIG_KVM) += kvm.o kvm-all.o
> obj-$(CONFIG_NO_KVM) += kvm-stub.o
>
> In this case makes sense to have an stub because there are lots of
> functions, but in the hpet case there are only two functions that are
> exported.  My problem with the "stub file" way is that we are going to
> end with three files by device (foo.c, foo-stub.c, foo.h).  Where
> foo-stub.c is basically trivial.
>
> I also removed the "info hpet" command.  I can be convinced that it is better 
> to change its
> output to
>        HPET is disabled by QEMU
> or
>        HPET is not present
> or any other stirng.
>
> Comments?  Any better suggestion?
>
> Later, Juan.
>
>
> Juan Quintela (6):
>   Create again config-device.h and config.devices.h
>   Move no_hpet declaration to hpet_emul.h
>   Move no_hpet test to inside hpet_init()
>   Make hpet_in_legacy_mode() return 0 for !TARGET_I386
>   make hpet_in_legacy_mode() return a bool
>   Create CONFIG_HPET
>
>  Makefile                           |    7 +++++--
>  Makefile.target                    |    8 ++++++--
>  config.h                           |   10 ++++++++++
>  default-configs/i386-softmmu.mak   |    1 +
>  default-configs/x86_64-softmmu.mak |    1 +
>  hw/hpet.c                          |    9 ++++++---
>  hw/hpet_emul.h                     |   20 +++++++++++++++++---
>  hw/mc146818rtc.c                   |    6 ------
>  hw/pc.c                            |    4 +---
>  hw/pc.h                            |    3 ---
>  monitor.c                          |    5 ++++-
>  11 files changed, 51 insertions(+), 23 deletions(-)



reply via email to

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