To my local tree I''m about to commit support for the notion of a "virtual cluster" for debugging purposes. The idea is that when one node (domain) in a cluster hits a breakpoint, all the other nodes are paused so that the first node doesn''t get voted out of the quorum. I''d be very surprised if there are other potential users for this functionality, but I''m asking just in case. The current implementation is done in such a way as to minimally perturb the existing interfaces to make it easy to carry it as an outside patch indefinitely. However, if others might use, it could be implemented more cleanly. -Kip ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> To my local tree I''m about to commit support for the notion of a > "virtual cluster" for debugging purposes. The idea is that when one > node (domain) in a cluster hits a breakpoint, all the other nodes are > paused so that the first node doesn''t get voted out of the quorum. I''d > be very surprised if there are other potential users for this > functionality, but I''m asking just in case. > > The current implementation is done in such a way as to minimally > perturb the existing interfaces to make it easy to carry it as an > outside patch indefinitely. However, if others might use, it could be > implemented more cleanly.I guess the ''nice'' way of doing this would be to have a notion of ''domain groups'', akin to process groups. This would be pretty trivial to hack in: * add a group_id integer to the domain struct. 0 is special = not grouped * add a domains struct * to create a circular list of domains in same group * add a dom0_op to set the group of a domain (scan domain list, adjust circular list) * on break point follow circular list issuing pause_domain(d) Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
That is almost exactly what I''ve done, except I didn''t add a
group id
and I used pad0 builddomain for a partner id (yes I know it is gross)
so the group would get set at buildtime.
And of course one cannot set domain 0 as a partner.
-Kip
> I guess the ''nice'' way of doing this would be to have a
notion of
> ''domain groups'', akin to process groups. This would be
pretty trivial to
> hack in:
> * add a group_id integer to the domain struct. 0 is special = not
> grouped
> * add a domains struct * to create a circular list of domains in same
> group
> * add a dom0_op to set the group of a domain (scan domain list, adjust
> circular list)
> * on break point follow circular list issuing pause_domain(d)
>
> Ian
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Please review the following diff. I will follow up with a signed off
patch with the required fixes.
http://www.fsmware.com/xenofreebsd/gdb/050318/clusterbkpt.diff
-Kip
On Fri, 18 Mar 2005 00:35:10 -0000, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
wrote:> > To my local tree I''m about to commit support for the notion
of a
> > "virtual cluster" for debugging purposes. The idea is that
when one
> > node (domain) in a cluster hits a breakpoint, all the other nodes are
> > paused so that the first node doesn''t get voted out of the
quorum. I''d
> > be very surprised if there are other potential users for this
> > functionality, but I''m asking just in case.
> >
> > The current implementation is done in such a way as to minimally
> > perturb the existing interfaces to make it easy to carry it as an
> > outside patch indefinitely. However, if others might use, it could be
> > implemented more cleanly.
>
> I guess the ''nice'' way of doing this would be to have a
notion of
> ''domain groups'', akin to process groups. This would be
pretty trivial to
> hack in:
> * add a group_id integer to the domain struct. 0 is special = not
> grouped
> * add a domains struct * to create a circular list of domains in same
> group
> * add a dom0_op to set the group of a domain (scan domain list, adjust
> circular list)
> * on break point follow circular list issuing pause_domain(d)
>
> Ian
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> Please review the following diff. I will follow up with a signed off > patch with the required fixes. > > http://www.fsmware.com/xenofreebsd/gdb/050318/clusterbkpt.diffKip, I think it would definitely be better to have a separate dom0 op to set the domain group rather having it as part of the create operation. It''s something that you might want to change after the domain''s creation (though create will fill in a default of groupid = domid). I''m not keen on the proliferation of dom0 ops, and I expect we''ll merge a number of them into a ''get/set domain parameter'' operation at some point, but for the moment, I think the best soloution is adding a DOM0_SETDOMAINGROUP. Thanks, Ian> > -Kip > > On Fri, 18 Mar 2005 00:35:10 -0000, Ian Pratt > <m+Ian.Pratt@cl.cam.ac.uk> wrote: > > > To my local tree I''m about to commit support for the notion of a > > > "virtual cluster" for debugging purposes. The idea is > that when one > > > node (domain) in a cluster hits a breakpoint, all the > other nodes are > > > paused so that the first node doesn''t get voted out of > the quorum. I''d > > > be very surprised if there are other potential users for this > > > functionality, but I''m asking just in case. > > > > > > The current implementation is done in such a way as to minimally > > > perturb the existing interfaces to make it easy to carry it as an > > > outside patch indefinitely. However, if others might use, > it could be > > > implemented more cleanly. > > > > I guess the ''nice'' way of doing this would be to have a notion of > > ''domain groups'', akin to process groups. This would be > pretty trivial to > > hack in: > > * add a group_id integer to the domain struct. 0 is special = not > > grouped > > * add a domains struct * to create a circular list of > domains in same > > group > > * add a dom0_op to set the group of a domain (scan domain > list, adjust > > circular list) > > * on break point follow circular list issuing pause_domain(d) > > > > Ian > > >------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> (though create will fill in a default of groupid = domid).That restriction is only a current limitation of the tools. I simply haven''t taken the time to set the option at runtime.> I''m not keen on the proliferation of dom0 ops, and I expect we''ll merge > a number of them into a ''get/set domain parameter''operation at some What is wrong with {GET/SET}DOMAININFO? These can be done at run-time. If you look, you''ll see that I explicitly handle the case of removing a domain from an existing group before adding it to another.> point, but for the moment, I think the best soloution is adding a > DOM0_SETDOMAINGROUP.I''m perfectly happy to do that, but I''d like to know why SETDOMAININFO doesn''t fit the bill. I would also appreciate feedback on the correctness of the locking. Thanks. -Kip ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> What is wrong with {GET/SET}DOMAININFO? These can be done at run-time. > If you look, you''ll see that I explicitly handle the case of removing > a domain from an existing group before adding it to another.GET/SETDOMAININFO is used for get/setting the CPU execution state. The IN parameteres are used for selecting an execution context, and adding a groupid parameter to them is certainly very odd. I don''t think the patch should touch xc_linux_build either -- setting the groupid is a generic thing that the tools can do after creating the domain. The rest looks fine. [When the domain is first created, groupid should be set to domid. When choosing a domid for a new domain, avoid picking domid''s that are still in use as a groupid by another domain.]> I would also appreciate feedback on the correctness of the locking.Locking looks OK to me, but I''m only reading the patch at the moment -- I always do a final look through after applying. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> GET/SETDOMAININFO is used for get/setting the CPU execution state. The > IN parameteres are used for selecting an execution context, and adding a > groupid parameter to them is certainly very odd.Good point. That would lead me to believe that they are slightly misnamed. Wouldn''t GET/SETDOMAINCONTEXT be more apt?> I don''t think the patch should touch xc_linux_build either -- setting > the groupid is a generic thing that the tools can do after creating the > domain.Fair enough. I can easily get carried away with what is most expedient for me. Which is why I sent a diff and not a patch. I knew it would come under the knife. When I check in a file, how do I make sure it stays executable? -Kip ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > GET/SETDOMAININFO is used for get/setting the CPU execution > state. The > > IN parameteres are used for selecting an execution context, > and adding a > > groupid parameter to them is certainly very odd. > > Good point. That would lead me to believe that they are slightly > misnamed. Wouldn''t GET/SETDOMAINCONTEXT be more apt?Indeed it would. A spring clean of the dom0 interface is certainly in order. The ''forcing factor'' for this will be when we move to more fine-grained privilege capabilities. Even the interface name dom0_op is no longer actually strictly correct...> When I check in a file, how do I make sure it stays executable?bk chmod +x foo.py Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel