hi, in my experimentation with xenbus, it seems that I get markedly different results when using straigth xs_write''s rather than nesting them inside transactions. I suppose that the idea is that the watches get triggered on transaction_end, but even if I enclose each xs_write in it''s own transaction I get different results. Are transactions working the way they are supposed to, or is my understanding wrong? Jacob -- Save time and bandwidth with EDelta: http://www.diku.dk/~jacobg/edelta/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5 Oct 2005, at 17:44, Jacob Gorm Hansen wrote:> in my experimentation with xenbus, it seems that I get markedly > different results when using straigth xs_write''s rather than nesting > them inside transactions. I suppose that the idea is that the watches > get triggered on transaction_end, but even if I enclose each xs_write > in it''s own transaction I get different results. > > Are transactions working the way they are supposed to, or is my > understanding wrong?Can you give a simple concrete example? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hmm it is not too simple, but if I run the code below as is, domU
succeeds in connecting netfront<->netback, e.g. there is no timeout
and the
MAC address is set correctly. If I rem in the xs_transaction_* calls,
the backend does not get the probe callback and nothing works.
Similar is true if I wrap each xs_write in a transaction_start-end pair.
char s[256];
char s2[256];
int vifid = 2000 + domid;
char* dom0_home = xs_get_domain_path(xs,0);
printf("dom0_home is %s\n",dom0_home);
char backend[256];
char frontend[256];
sprintf(backend,"%s/backend/vif/%d/%d",dom0_home,vifid,domid);
sprintf(frontend, "%s/device/vif/%d",home,vifid);
//xs_transaction_start(xs);
sprintf(s,"%s/frontend",backend);
xs_w(s, frontend );
sprintf(s,"%s/frontend-id",backend);
sprintf(s2,"%d",domid);
xs_w(s, s2 );
sprintf(s,"%s/handle",backend);
sprintf(s2,"%d",vifid);
xs_w(s, s2);
//xs_transaction_end(xs,0);
//xs_transaction_start(xs);
sprintf(s, "%s/backend-id", frontend);
xs_w(s, "0");
sprintf(s,"%s/backend",frontend);
xs_w(s, backend );
sprintf(s,"%s/handle",frontend);
sprintf(s2,"%d",vifid);
xs_w(s, s2);
sprintf(s,"%s/mac",frontend);
xs_w(s, "aa:00:00:11:a6:02");
//xs_transaction_end(xs,0);
Jacob
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
What snapshot of unstable are you using? The only thing different about transactions is that slow things down a bit. It would indicate you''re seeing race conditions. Note, that I''ve not been able to recreate the problems you''re having with your code. What OS are you using? Do you have patches against unstable? Regards, Anthony Liguori Jacob Gorm Hansen wrote:>Hmm it is not too simple, but if I run the code below as is, domU >succeeds in connecting netfront<->netback, e.g. there is no timeout >and the >MAC address is set correctly. If I rem in the xs_transaction_* calls, >the backend does not get the probe callback and nothing works. > >Similar is true if I wrap each xs_write in a transaction_start-end pair. > > char s[256]; > char s2[256]; > > int vifid = 2000 + domid; > > char* dom0_home = xs_get_domain_path(xs,0); > printf("dom0_home is %s\n",dom0_home); > > char backend[256]; > char frontend[256]; > sprintf(backend,"%s/backend/vif/%d/%d",dom0_home,vifid,domid); > sprintf(frontend, "%s/device/vif/%d",home,vifid); > > > //xs_transaction_start(xs); > > sprintf(s,"%s/frontend",backend); > xs_w(s, frontend ); > > sprintf(s,"%s/frontend-id",backend); > sprintf(s2,"%d",domid); > xs_w(s, s2 ); > > sprintf(s,"%s/handle",backend); > sprintf(s2,"%d",vifid); > xs_w(s, s2); > > > //xs_transaction_end(xs,0); > > //xs_transaction_start(xs); > > > sprintf(s, "%s/backend-id", frontend); > xs_w(s, "0"); > > sprintf(s,"%s/backend",frontend); > xs_w(s, backend ); > > sprintf(s,"%s/handle",frontend); > sprintf(s2,"%d",vifid); > xs_w(s, s2); > > sprintf(s,"%s/mac",frontend); > xs_w(s, "aa:00:00:11:a6:02"); > > //xs_transaction_end(xs,0); > >Jacob > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:> What snapshot of unstable are you using? > > The only thing different about transactions is that slow things down a > bit. It would indicate you''re seeing race conditions. > > Note, that I''ve not been able to recreate the problems you''re having > with your code. What OS are you using? Do you have patches against > unstable?Hmm perhaps this is due to me being on a single CPU without SMT? Could explain why my races are different? Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen wrote:>On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote: > > >>What snapshot of unstable are you using? >> >>The only thing different about transactions is that slow things down a >>bit. It would indicate you''re seeing race conditions. >> >>Note, that I''ve not been able to recreate the problems you''re having >>with your code. What OS are you using? Do you have patches against >>unstable? >> >> > >Hmm perhaps this is due to me being on a single CPU without SMT? Could >explain why my races are different? > >I''m also on a single CPU w/o SMT :-) Regards, Anthony Liguori>Jacob > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel