5:08 p.m.
On 11/12/2013 10:27 PM, Xu Wang wrote:
δΊ 2013/11/13 8:59, John Ferlan ει:
Dear John,
My idea is, using a data structure (a link list) to keep the elements
left after all kinds of
virtual devices fetched tags they needed from xml. And if I just mark a
node of others with
status instead of delete it, the whole structure of xml could be saved
as well.
The introduction of 'id' in 'others' structure is to identify several
<tags> with the same
name. The console device support new introduced and some tags in
'unknown_device'
have to use 'id' to identify elements. It maybe a little coarse now so I
need any suggestion
from you to make it works better. If you have any better idea to solve
the unsupported
tags missing issue please share with me :-) Because so many patches
about it merged
and there will be more in the future.
These 48 patches just the first part in my designing. After that I want
to build the
management about all data (even in 'others' member). And all of these
updates are
compatitable with older version libvirt-cim. So the upper layer need
little change and
keep the original feature but could make libvirt-cim becomes more powerful.
XFAIL about hotplug disappeared after updated. About the warning you
mentioned above
I'll check and fix it in the new version.
Thanks,
Xu Wang
I don't have any thoughts on better ideas - it's just not my focus.
There's a lot of changes being made in this series which I suppose in
hindsight would have been nice to have been broken up a bit more to make
it manageable to review, understand, and test. I've started with the
first 3 patches as it seems all they do is create infrastructure and
"for the most part" no one should be calling them.
I started with patch 1... got to patch 2 and had issues. I ran patch 2
through coverity and it complained about the memset() in
cleanup_virt_device().
A recent patch changed that from "memset(&dev->dev, 0,
sizeof(dev->dev));" to "memset(dev, 0, sizeof(*dev));". Coverity
complained about the path from "classify_resources()" for
CIM_RES_TYPE_DISK into the rasd_to_vdev() call, then into
_sysvirt_rasd_to_vdev(), disk_rasd_to_vdev(), and finally
cleanup_virt_device().
It seems the change to device_parsing.h, inclusion by
Virt_VirtualSystemManagementService.c, and usage of virt_device as a
static structure caused the "issue" as a "clean" build fixed things.
Although it took a while for me to figure it out. I suppose that's more
a build/Makefile issue than anything else...
The second issue I've run into is that by only applying the first two
patches, I can get a test to cause cimprovagt to fail:
--------------------------------------------------------------------
VirtualSystemManagementService - 16_removeresource.py: FAIL
ERROR - (1, u'CIM_ERR_FAILED: Lost connection with cimprovagt
"libvirt-cim".')
InvokeMethod(RemoveResourceSettings): CIM_ERR_FAILED: Lost connection
with cimprovagt "libvirt-cim".
--------------------------------------------------------------------
This one's really frustrating as I'm really perplexed why a possible fix
could work. It seems if I don't call cleanup_others() from
cleanup_unknown_device(), then I don't get that core. I have no idea
why though. Is it possibly related to the static usage of virt_device? I
see this even after a clean build.
Maybe this "cleanup_unknown_device()" and it's counter-part
"dev_unknown" should have been added after the others work. It seems
there are two things being done at once - creating an 'others' list to
store the read xml and creating a list of unknown devices.
You've done a lot of work and it seems promising as a way handle new
tags. Of course I ask myself why is it so important to go through this
exercise. Are the libvirt API's deficient? I would think libvirt
should be the only thing handling XML format and the applications that
use libvirt would have API's to create, define, get, set, start, stop,
etc VM's. Having to store the XML is "dangerous" insomuch as we've
already found it can change and libvirt-cim cannot keep up.
Anyway, as an exercise for me to learn and because I pushed a number of
changes which conflict with what you've already done... I will try to
help with the effort to compact each patch series into manageable parts.
FWIW: I pushed the other patches because they were posted first - I just
went in order.
John