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). It is basically independent of almost everything else. > But I'm also not convinced about the general approach. Except for RHEL > packagers, no one seems to gain any benefit from having CONFIG_HPET. 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 shipping a device is that we are going to support it for 7 years, you can guess why we want to be conservative. > The > HPET model is still incomplete in has some remaining quicks (hold on for > improvements), but that doesn't qualify it for !CONFIG_HPET, > specifically as it is deeply hooked into every modern PC. If I was > asked, I guess I would nack this switch. Then, what should we do? 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. Here we are, and device is still not fixed, what to do? Another local patch? Just get upstream to integrate a sane way to disable it and let in enable by default? 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. Later, Juan.
