On 05/24/2010 07:54 PM, Juan Quintela wrote:
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return 0;}
#endif
Change this
Paolo Bonzini wrote:
On 05/24/2010 07:54 PM, Juan Quintela wrote:
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return
On 05/25/2010 11:05 AM, Jan Kiszka wrote:
Please don't waste your time:
http://permalink.gmane.org/gmane.comp.emulators.qemu/71377
I wasn't going to. :-) I had seen the series---very nice work!
Paolo
Juan Quintela wrote:
Hi
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
Jan Kiszka jan.kis...@web.de wrote:
Juan Quintela wrote:
Unless this is deadly urgent, please hold it back until we sorted out
some more fundamental issues with the HPET, specifically ported it to qdev.
This series are independent of the qdev change (it almost don't change
hpet code at all).
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.
Juan Quintela wrote:
Jan Kiszka jan.kis...@web.de wrote:
Juan Quintela wrote:
Unless this is deadly urgent, please hold it back until we sorted out
some more fundamental issues with the HPET, specifically ported it to qdev.
This series are independent of the qdev change (it almost don't
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
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
On 05/24/2010 12:11 PM, Paul Brook wrote:
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-
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)
On 05/24/2010 12:54 PM, Juan Quintela wrote:
Paul Brookp...@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
Jan Kiszka jan.kis...@web.de wrote:
This happens to us all the time for lots of devices. And the big
problem is that there is no sane way to disable them :(
If we can agree in a mechanism to disable them (like this one) or
something similar, we could remove it.
Our biggest problem with
Anthony Liguori wrote:
On 05/24/2010 12:54 PM, Juan Quintela wrote:
Paul Brookp...@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
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
Juan Quintela wrote:
We already have to disable hpet for 5.4 (1 year ago). It was done with
a local hack because it was supposed that for next big release it would
have been fixed.
But this remains a RHEL issue. Redhat decided to compile out features
that are unsupported, others seem to
On Mon, May 24, 2010 at 6:03 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 05/24/2010 12:54 PM, Juan Quintela wrote:
Paul Brookp...@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
17 matches
Mail list logo
