qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model
Date: Mon, 25 Jul 2011 07:45:48 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 07/25/2011 06:21 AM, Kevin Wolf wrote:
Am 25.07.2011 03:44, schrieb Anthony Liguori:
Hi,

This series is the rough beginnings of the QEMU Object Model.  This is basically
qdev generalized on steroids.

This series includes the core infrastructure, a strawman Device type, and
the beginnings of the conversion of CharDriverState.  This is in a rougher
state than I would like it to be but I wanted to get the concepts on the list
as soon as possible.

My plan is to drop the Device parts from future versions of the series and just
focus on backends to start with.

Please note that this series has an awful lot of ramifications.  Most of our
current command line options would become deprecated, the build system will
change significantly, and a lot of our QMP functions will become deprecated.

It seems like a lot of change, but hopefully this series illustrates how we
can do it very incrementally with value being added at each stage of the
conversion.

I haven't looked in much detail at it yet, but it has still the same
problem I was talking about last week: Patches 17-21 don't actually
convert existing code, but they add new code.

Actually, it's mostly existing code. In terms of incremental conversion, the most straight forward way is to adds the new version side-by-side with the old version and then remove the old version.

Converting in device in place requires some gymnastics. If you think it's absolutely critical, I could try to do it but I'm not sure I agree it's the thing to do.

This means that we can't
review only the changes, but have to review the whole code. It also
makes conflicts with patches modifying the old version hard to even notice.


On another note, I'm not so sure if your renaming is really helpful. It
doesn't matter that much with qemu-char because someone thought having
the function pointers in CharDriverState was a good idea, but if you're
consistent, the rename would go like this in the block layer:

BlockDriverState ->  BlockDriver
BlockDriver ->  BlockDriverClass

I think we do need to introduce consistent naming conventions.

If those conventions are FooState and Foo, that could be okay, but the code base today is absolutely not consistent on it.

I think Foo and FooClass is better because Foo is the most common usage of the type and it's less characters to type.

Regards,

Anthony Liguori


IMHO, that's not very helpful, but just going to create confusion. We
could probably discuss other parts of the terminology, too, but let's
save the bikeshedding for later.

Kevin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]