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 change > hpet code at all). It is basically independent of almost everything else.
It causes mechanical breakage to the qdev change (and the one I'm hacking on ATM). > >> 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. In this particular case, it is a one line patch: "no_hpet = 1;", hardwired. > >> 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? Help fixing it (e.g. testers will soon be welcome). > 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 handle this differently. > > 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? Let's start with listing your requirements to no longer disable HPET. That would already help us to asses how long !CONFIG_HPET would actually be of any use at all. I'm yet optimistic that we can resolve most if not all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13 material anyway. > > 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. At least HPET is IMHO a bad example as it is, just like e.g. the IOAPIC, an essential part of today's x86 systems. Jan
signature.asc
Description: OpenPGP digital signature
