Juan Quintela wrote: > Paul Brook <p...@codesourcery.com> wrote: >>> On 05/24/2010 11:32 AM, Paul Brook wrote: >>>>> Notice that this patch was sent against hpet as one example, if we agree >>>>> that this "way" of disabling devices is ok, we could disable more >>>>> devices/have more flexibility. Notice that in general, we (RHEL/KVM) >>>>> are interested in a small subset of qemu devices. >>>> IMO this patch is a backwards step. The device models should be cleaned >>>> up so that you don't need to make a compile time decision. >>> I disagree. I think the device model should be cleaned up so that no >>> CONFIG_HPET is required in code but I think it's still useful to be able >>> to exclude device models from the build. That should just be a matter >>> of not building the object though (that's the point of device_init()). >> I think we're saying the same thing. >> >> We already have a mechanism for avoiding things at build time - specifically >> config-devices.mak. We don't have a nice UI for it, but it's there. >> At worst your distro specific patch is a 1-line change to default- >> configs/i386-softmmu.mak. >> >> I have no objection to moving hpet.c into Makefile.objs, conditional on >> CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary >> prerequisite is that you fix the device model and machine initialisation so >> that it's possible to omit hpet.o without rebuilding anything else. > > We have two exported functions: > > void hpet_init(qemu_irq *irq); > uint32_t hpet_in_legacy_mode(void);
One, hpet_in_legacy_mode will become hpet-private. Once done, I will have a look if we can cleanly push more x86 platform logic related to the HPET IRQ routing into hpet_init. Jan
signature.asc
Description: OpenPGP digital signature
