On 03/05/2012 12:22 PM, Avi Kivity wrote:
On 03/05/2012 08:16 PM, Anthony Liguori wrote:
We're pretty close to being there. Luiz, about how long do you
think before we get there?
It's a pity to add new commands along the way.
It's more complicated than this unfortunately.
A client needs to be able to determine whether the 'screendump'
command works as expected. Unfortunately, when QXL was introduced,
'screendump' became broken across multiple releases.
screendump is the right interface, but since it was broken in multiple
releases, we need another command for a client to determine that it's
not broken. In the short term, screendump_async is that. After QAPI,
it will probably be a screendump2.
I don't mind introducing short term commands and then deprecating it
particularly when they are marked as such.
Zooming out from screendump, there are several ways to deal with broken
commands:
1. introduce new commands
This is our only short term options for this specific circumstance.
2. introduce capabilities that say "screendump is fixed wrt bug so-and-so"
We don't have such a mechanism and I generally would prefer to avoid it.
There's a certain shame in introducing new commands that hopefully will cause us
to be more careful in the future.
3. fix it and backport the fix to a stable release
This is only not practical because it requires such an infrastructure change.
4. ignore the broken command and hope
5. just tell clients to rely on version information and ignore the existence of
downstreams
This is really mostly a downstream problem, not an upstream problem. Version
numbers can be reliable here for upstream.
This is the approach that would be typically taken for a C library. The flip
side is that this is also while we end up with autotools and a bunch of compile
time tests to determine what broken functions exist.
Regards,
Anthony Liguori
My preference is 3->2->1->4, or we'll end up with screendump65535 soon.
