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
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_m
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 to
On Mon, May 24, 2010 at 6:03 PM, Anthony Liguori wrote:
> On 05/24/2010 12:54 PM, Juan Quintela wrote:
>>
>> Paul Brook 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
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
Juan Quintela wrote:
> Paul Brook 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
Anthony Liguori wrote:
> On 05/24/2010 12:54 PM, Juan Quintela wrote:
>> Paul Brook 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 c
Jan Kiszka 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 ship
On 05/24/2010 12:54 PM, Juan Quintela wrote:
Paul Brook 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
Paul Brook 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)
>> >> ar
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-
confi
> 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
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 devic
Juan Quintela wrote:
> Jan Kiszka 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
>
> 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 s
Jan Kiszka 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). It is basicall
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
Juan Quintela 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-d
18 matches
Mail list logo