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 -- 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
