Hi, A talk about gdbsx at the last summit looks very useful. Is there any roadmap to include it into the tree? Or at least some supports for it is merged, so it can stay outside the tree if that is more desired? Thanks, Jun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s being maintained as an external repository: http://xenbits.xensource.com/ext/debuggers.hg. Unfortunately it apparently isn''t a clone of xen-unstable.hg but a 3-month old copy which has not since been resynchronised. Mukesh: I would recommend you maintain a patch queue or a tree whose parent is xen-unstable.hg, which you can periodically pull from and re-merge your patches. Otherwise you have a debugger for an old fixed version of xen-unstable.hg which is rather less useful in the long run. -- Keir On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote:> Hi, > > A talk about gdbsx at the last summit looks very useful. Is there any > roadmap to include it into the tree? Or at least some supports for it > is merged, so it can stay outside the tree if that is more desired? > > Thanks, > Jun > > _______________________________________________ > 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 Tue, Sep 2, 2008 at 1:06 AM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:> It''s being maintained as an external repository: > http://xenbits.xensource.com/ext/debuggers.hg. > > Unfortunately it apparently isn''t a clone of xen-unstable.hg but a 3-month > old copy which has not since been resynchronised. Mukesh: I would recommend > you maintain a patch queue or a tree whose parent is xen-unstable.hg, which > you can periodically pull from and re-merge your patches. Otherwise you have > a debugger for an old fixed version of xen-unstable.hg which is rather less > useful in the long run.So it have a good chance to be merged? Cool! Mukesh: Could you explain a bit the advantage of gdbsx over the current implementation that is already in tree? I figured out some, but still might miss some. That is not very clear from the slides. Thanks, J> On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote: > >> Hi, >> >> A talk about gdbsx at the last summit looks very useful. Is there any >> roadmap to include it into the tree? Or at least some supports for it >> is merged, so it can stay outside the tree if that is more desired? >> >> Thanks, >> Jun >> >> _______________________________________________ >> 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 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote:>> Unfortunately it apparently isn''t a clone of xen-unstable.hg but a 3-month >> old copy which has not since been resynchronised. Mukesh: I would recommend >> you maintain a patch queue or a tree whose parent is xen-unstable.hg, which >> you can periodically pull from and re-merge your patches. Otherwise you have >> a debugger for an old fixed version of xen-unstable.hg which is rather less >> useful in the long run. > > So it have a good chance to be merged? Cool!It has some chance, if it is used and if it is cleanly implemented. Equally for now it ought to be able to live quite happily outside of the main repository. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
yeah, I''ve been meaning to refresh for a while now, but time just flies by. Anyhoo, the ext tree is refreshed now. I did it in two steps so that one could easily come up with a patch for 3.3.0 and another refresh to latest. Hopefully, any time soon, I''ll stop spending time on dealing with time issues in debugger and have the time to put patches somewhere in timely manner, because its no fun when time goes backwards, or forwards so faaast... thanks, Mukesh Keir Fraser wrote: > It''s being maintained as an external repository: > http://xenbits.xensource.com/ext/debuggers.hg. > > Unfortunately it apparently isn''t a clone of xen-unstable.hg but a 3-month > old copy which has not since been resynchronised. Mukesh: I would recommend > you maintain a patch queue or a tree whose parent is xen-unstable.hg, which > you can periodically pull from and re-merge your patches. Otherwise you have > a debugger for an old fixed version of xen-unstable.hg which is rather less > useful in the long run. > > -- Keir > > On 1/9/08 16:59, "Jun Koi" <junkoi2004@gmail.com> wrote: > >> Hi, >> >> A talk about gdbsx at the last summit looks very useful. Is there any >> roadmap to include it into the tree? Or at least some supports for it >> is merged, so it can stay outside the tree if that is more desired? >> >> Thanks, >> Jun >> >> _______________________________________________ >> 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
>Mukesh: Could you explain a bit the advantage of gdbsx over the>current implementation that is already in tree? I figured out some, >but still might miss some. That is not very clear from the slides. I''ve not used the current implementation in the tree so can''t compare. The main reason for gdbsx is because we use 32bit dom0 on 64bit hypervisor, and I couldn''t get libxc to support that after a lot of effort. What I can tell you about gdbsx is, it''s a clean, simplified, lightweight implementation, that relies on the hyp for most of the work with minimal changes. It supports all guests, PV or HVM, 32bit or 64bit. Keir Fraser wrote: > On 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote: > > It has some chance, if it is used and if it is cleanly implemented. Equally > for now it ought to be able to live quite happily outside of the main > repository. > > -- Keir gdbsx currently works on 32bit dom0 running on 64bit hyp, hence, probably not ready for the main repo. OTOH, kdb is getting there.... thanks, mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Sep 4, 2008 at 7:57 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:> >>Mukesh: Could you explain a bit the advantage of gdbsx over the >>current implementation that is already in tree? I figured out some, >>but still might miss some. That is not very clear from the slides. > > I''ve not used the current implementation in the tree so can''t compare. > The main reason for gdbsx is because we use 32bit dom0 on 64bit hypervisor, > and I couldn''t get libxc to support that after a lot of effort. > > What I can tell you about gdbsx is, it''s a clean, simplified, lightweight > implementation, that relies on the hyp for most of the work with minimal > changes. It supports all guests, PV or HVM, 32bit or 64bit.Thanks. I will look at the code and get back if I have more questions.> > > Keir Fraser wrote: >> On 1/9/08 17:15, "Jun Koi" <junkoi2004@gmail.com> wrote: >> >> It has some chance, if it is used and if it is cleanly implemented. >> Equally >> for now it ought to be able to live quite happily outside of the main >> repository. >> >> -- Keir > > gdbsx currently works on 32bit dom0 running on 64bit hyp, hence, probably > not ready for the main repo. OTOH, kdb is getting there.... >gdbsx can happily stay outside tree as long as your changes to hypercalls are merged. So it is important to get those hypercalls in. Thanks, Jun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel