On Tue, Oct 16, 2012 at 10:49:38AM -0600, Alex Williamson wrote: > On Tue, 2012-10-16 at 17:23 +0200, Michael S. Tsirkin wrote: > > On Tue, Oct 16, 2012 at 09:13:15AM -0600, Alex Williamson wrote: > > > > There's no chance we ship e.g. q35 by mistake without this API: since > > > > there is no way this specific assert can be missed in even basic > > > > testing: > > > > > > > > So I see it differently: > > > > > > > > As coded here: > > > > chipset authors get lazy and do not implement API. > > > > bad performance for all users. > > > > > > > > With assert: > > > > chipset authors implement necessary API. > > > > good performance for all users. > > > > > > I prefer a carrot, not a whip. Thanks, > > > > > > Alex > > > > > > > It's not just that. > > Problem is performance testing/fixing is hard. > > Getting an error_report from the driver saying it's using a slow path > and why makes that significantly easier. > > > Catching and fixing asserts is easy. > > Easy for who? The user trying to test a feature? Probably not. Me, > who may not have access to the chipset documentation or understand the > platform? Maybe, maybe not. > > > So working around buggy qemu code really backfires > > as it reverses the motivation for writing well performing > > code. History proves me right: for each API change where > > we implemented a fallback old code stayed around for years. > > Does that necessarily mean it was wrong? How many of those API changes > added new features that may have been abandoned if the developer was > required to make sweeping changes to get their code accepted? If not > abandoned, how much delayed? How many land mines might we have in the > code for changes that were done incorrectly or missed? I don't > understand why adding robustness to the API is such a contentious point, > but it's your prerogative, just as it's mine to avoid using that API > arbitrarily. Thanks, > > Alex Yea. All I say is, I intend to fix things so you don't need to probe for this API. I think it does not make sense to add a temporary API as a stopgap for this since it will solve no actual problem. If e.g. Jason finds it hard to add this to q35, we could add a stopgap solution for vfio. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
