xen-devel
[Xen-devel] RE: [PATCH][ioemu] in xenstore_process_dm_command_event(), x
To: |
Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> |
Subject: |
[Xen-devel] RE: [PATCH][ioemu] in xenstore_process_dm_command_event(), xs_rm the command node after we read it. |
From: |
"Cui, Dexuan" <dexuan.cui@xxxxxxxxx> |
Date: |
Fri, 19 Jun 2009 10:01:25 +0800 |
Accept-language: |
zh-CN, en-US |
Acceptlanguage: |
zh-CN, en-US |
Cc: |
Keir, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <Keir.Fraser@xxxxxxxxxxxxx>, Simon Horman <horms@xxxxxxxxxxxx> |
Delivery-date: |
Thu, 18 Jun 2009 19:04:16 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<19002.17997.72035.503780@xxxxxxxxxxxxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<EADF0A36011179459010BDF5142A457501C9D98D00@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18999.54551.711286.625101@xxxxxxxxxxxxxxxxxxxxxxxx> <EADF0A36011179459010BDF5142A457501C9D98D07@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <EADF0A36011179459010BDF5142A457501C9D98D09@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19002.17997.72035.503780@xxxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AcnwG9q8VdSSo6xXQCa3aUp3PoORKQAYllhQ |
Thread-topic: |
[PATCH][ioemu] in xenstore_process_dm_command_event(), xs_rm the command node after we read it. |
> Ian Jackson wrote:
> > When we start processing a command we should either (i) delete it from
> > xenstore immediately, so that future watch triggerings either don't
> > see the command or actually see genuine new invocations,
Maybe I misunderstood this. I thought I should rm the 'path' (namely the
'command') as the above suggested.
rm the 'command' itself would trigger 1 more watch fire, and the watch handler
in qemu-dm trying to xs_read_watch() gets a NULL and ignores this fire. The
patch can fix the issue I meet with.
Actually I'm not very familiar with the protocols among xenstored,qemu-dm and
xend as there is no document/comment at all... Looks there are some simple
sync mechanism in xend/qemu-dm, but I don't think they are enough.
I'll appreciate it if you could help to do an analysis and ducoment the
protocols by comments. :-)
Thanks,
-- Dexuan
-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
Sent: 2009?6?18? 21:51
To: Cui, Dexuan
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser; Simon Horman
Subject: Re: [PATCH][ioemu] in xenstore_process_dm_command_event(), xs_rm the
command node after we read it.
Cui, Dexuan writes ("[PATCH][ioemu] in xenstore_process_dm_command_event(),
xs_rm the command node after we read it."):
> + if (!xs_rm(xsh, XBT_NULL, path))
> + fprintf(logfile, "xs_rm failed: path=%s\n", path);
> +
Are you sure this is right ? What normally removes this path ?
Should that other code be deleted ?
Will bringing the removal forward have any other implications ?
As I said:
If you do this, make sure that you don't give xend the impression
it's safe to overwrite the parameters of the old command until
you've read them all. Otherwise two commands in quick succession
(or simultaneously) will go wrong.
Ideally the protocol would be documented somewhere, at least in a
comment. Then it would be easy to see whether it was a correct
protocol, and whether each side implemented it correctly.
If you don't have time to do this kind of analysis just say, and I'll
look at it all in more detail.
Sorry to be sceptical. In the meantime I'll apply your patch :-).
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|