On 08/30/2010 11:16 AM, Luiz Capitulino wrote:
On Mon, 30 Aug 2010 10:38:45 -0500
Anthony Liguori<anth...@codemonkey.ws> wrote:
On 08/30/2010 10:28 AM, Anthony Liguori wrote:
Having two interfaces guarantees failure. What's the separation
between internal and external? Is qdev internal or external?
Let me put it another way, compatibility cannot be an after thought.
We need to think deeply about compatibility when we design our
interfaces and we're going to have to redesign interfaces with
compatibility in mind. It's a hard problem but it's solvable. Just
defaulting arguments in QMP doesn't do anything to improve compatibility.
The point is: C compat sucks, QMP's doesn't. QMP will suck too if we direct
map the two.
Prove it because I don't believe you :-)
Here's a counter example. Let's say we have function do_something that
takes three arguments. We add a forth additional argument and default
it. And old client can call with three arguments and it just works
because the default is "do what we used to do".
How do we discover if this new version of do_something supports four
arguments instead of three? Do we ignore unknown arguments? We can't
because that fourth argument may be important (but guess what, we do
today and that's busted). Because I might be passing "do something new"
as the fourth argument because I expressly didn't want the old behavior.
Okay, so now we have to add a mechanism to enumerate function names and
their arguments. Now I can detect the fourth argument. What if the
argument is a structure and we want to add a new field to the structure?
How do I know, as a client, that I can add another field to the
structure and that field will be respected?
You'd end up writing a full blown schema and then enforcing the schema.
As a client, you'd have to download the schema and then try to detect
the features a command supported. That's an absolutely awful compat
interface IMHO especially if you have different downstream schemas.
On the other hand, introducing a new function that takes a fourth
argument, or a new type of structure with an added argument simplifies
the problem tremendously. It means we might have four versions of the
same function but that's unavoidable. Flattening this for the client
makes their lives much simpler.
We cannot radically change our internal implementations and expect to
bridge it all in some special sauce code somewhere.
This also suggests that we're going to have to practice deprecation to
evolve our APIs in a reasonable fashion.
Deprecation should be mostly used for bad defined commands, not for simple
extensions.
It's better to talk about concrete things so please give an example of
how you can provide compatibility in QMP that you can't do in C and we
can discuss it.
My position is that we aren't any closer to having compatible APIs then
we were with the human monitor. I think we need to focus on
compatibility and that that has to be solved as the QEMU interface
level. I contend that it's not solvable at the QMP level.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
