Quoting Kieran Bingham (2019-03-26 01:52:10) > Hi Stephen, > > On 25/03/2019 18:45, Stephen Boyd wrote: > > Implement gdb functions for rb_first(), rb_last(), rb_next(), and > > rb_prev(). These can be useful to iterate through the kernel's red-black > > trees. > > I definitely approve of getting data-structure helpers into scripts/gdb, > as it will greatly assist debug options but my last attempt to do this > was with the radix-tree which I had to give up on as the internals were > changing rapidly and caused continuous breakage to the helpers.
Thanks for the background on radix-tree. I haven't looked at that yet, but I suppose I'll want to have that too at some point. > > Do you foresee any similar issue here? Or is the corresponding RB code > in the kernel fairly 'stable'? > > > Please could we make sure whomever maintains the RBTree code is aware of > the python implementation? > > That said, MAINTAINERS doesn't actually seem to list any ownership over > the rb-tree code, and get_maintainers.pl [0] seems to be pointing at > Andrew as the probable route in for that code so perhaps that's already > in place :D I don't think that the rb tree implementation is going to change. It feels similar to the list API. I suppose this problem of keeping things in sync is a more general problem than just data-structures changing. The only solution I can offer is to have more testing and usage of these scripts. Unless gdb can "simulate" or run arbitrary code for us then I think we're stuck reimplementing kernel internal code in gdb scripts so that we can get debug info out.