Stanislav Fomichev <sdf@xxxxxxxxxxx> [Thu, 2020-02-27 10:01 -0800]: > On 02/26, Andrey Ignatov wrote: > > drgn is a debugger that reads kernel memory and uses DWARF to get types > > and symbols. See [1], [2] and [3] for more details on drgn. > > > > Since drgn operates on kernel memory it has access to kernel internals > > that user space doesn't. It allows to get extended info about various > > kernel data structures. > > > > Introduce bpf.py drgn script to list BPF programs and maps and their > > properties unavailable to user space via kernel API. > Any reason this is not pushed to https://github.com/osandov/drgn/ ? > I have a bunch of networking helpers for drgn as well, but I was > thinking about contributing them to the drgn github, not the kernel. > IMO, seems like a better place to consolidate all drgn stuff. I have this part in the commit message: > > The script can be sent to drgn repo where it's easier to maintain its > > "drgn-ness", but in kernel tree it should be easier to maintain BPF > > functionality itself what can be more important in this case. That's being said it's debatable which place is better and I'm still trying to figure it out myself since, from what i see, there is no widely adopted practice. I've been contributing to drgn as well mostly in two forms: * helpers [1]; * examples [2] And so far I used examples/ dir as a place to keep small useful "tools" (tcp_sock.py, cgroup.py, bpf.py). But there is no place for bigger "scripts" or "tools" in drgn (yet?). On the other hand I see two drgn scripts in kernel tree already: * tools/cgroup/iocost_coef_gen.py * tools/cgroup/iocost_monitor.py So maybe it's time to discuss where to keep tools like this in the future. In this specifc case I'd love to see feedback from Omar and BPF maintainers. [1] https://github.com/osandov/drgn/tree/master/drgn/helpers/linux [2] https://github.com/osandov/drgn/tree/master/examples/linux -- Andrey Ignatov
