Re: [PATCH bpf-next] bpf: Add drgn script to list progs/maps

From: Daniel Borkmann <daniel@iogearbox.net>
To: Andrey Ignatov <rdna@fb.com>,
	Stanislav Fomichev <sdf@fomichev.me>,
	osandov@fb.com, ast@kernel.org
Cc: bpf@vger.kernel.org, kernel-team@fb.com, tj@kernel.org
Subject: Re: [PATCH bpf-next] bpf: Add drgn script to list progs/maps
Date: Thu, 27 Feb 2020 22:11:28 +0100	[thread overview]
Message-ID: <8cbe6219-004c-e4f0-5f1e-5270c326f21b@iogearbox.net> (raw)
In-Reply-To: <20200227182653.GC29488@rdna-mbp>

[ +tj ]

On 2/27/20 7:26 PM, Andrey Ignatov wrote:
> Stanislav Fomichev <sdf@fomichev.me> [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.

I can certainly see both sides given that drgn tools have been added to
tools/cgroup/ already. I presume if so, then these could live in tools/drgn/
which would also make it more clear what is needed to run as dependency
plus there should be be a proper high-level readme to document what developers
need to run in order to run them. But from looking at [1], I can also see that
those scripts would depend on new helpers being added/updated/deleted, so it
might be easier to add drgn/tools/ directory where scripts could be updated
in one go with updates to drgn helpers. Either way, I think it would be nice
to add documentation somewhere for getting people started.

> [1] https://github.com/osandov/drgn/tree/master/drgn/helpers/linux
> [2] https://github.com/osandov/drgn/tree/master/examples/linux