Introduce a command to inspect the running system

[atenart]

Introduces retis inspect to inspect the running system. Currently it only supports listing compatible probes.

$ retis inspect -p 'tp:*'
...
$ retis inspect -p 'kprobe:*tcp*'
...

Performance is not great when listing huge lists of probes, eg -p kprobe:* (~20s on my laptop). The main culprit is btf-rs, we might work on this at some point (once there are less PRs pending there and if possible, as quick tests showed no real improvement).

Fixes #285 and #293.

[atenart]

Rawhide runtime CI issue is fixed in #332.

[atenart]

Rebased on top of main.

[atenart]

Rebased on top of main to resolve conflicts. No other change intended.

[vlrpl]

Introduces retis inspect to inspect the running system. Currently it only supports listing compatible probes.

$ retis inspect -p 'tp:*'
...
$ retis inspect -p 'kprobe:*tcp*'
...

Performance is not great when listing huge lists of probes, eg -p kprobe:* (~20s on my laptop). The main culprit is btf-rs, we might work on this at some point (once there are less PRs pending there and if possible, as quick tests showed no real improvement).

I tried -p without any parameter and took 103s. It's a bit too high to make it useful. The user would probably think the command is stuck in an infinite loop. What about (keeping the logic) making the argument for -p option mandatory until the limitation gets lifted? Also, I would suggest documenting the fact it could take a while for wildcarded args.

Fixes #285 and #293.

[atenart]

Performance is not great when listing huge lists of probes, eg -p kprobe:* (~20s on my laptop). The main culprit is btf-rs, we might work on this at some point (once there are less PRs pending there and if possible, as quick tests showed no real improvement).

I tried -p without any parameter and took 103s. It's a bit too high to make it useful.

Ouch.

The user would probably think the command is stuck in an infinite loop. What about (keeping the logic) making the argument for -p option mandatory until the limitation gets lifted? Also, I would suggest documenting the fact it could take a while for wildcarded args.

Makes sense, I'll do the above for the next version of this PR.

[vlrpl]

Performance is not great when listing huge lists of probes, eg -p kprobe:* (~20s on my laptop). The main culprit is btf-rs, we might work on this at some point (once there are less PRs pending there and if possible, as quick tests showed no real improvement).

I tried -p without any parameter and took 103s. It's a bit too high to make it useful.

Ouch.

The user would probably think the command is stuck in an infinite loop. What about (keeping the logic) making the argument for -p option mandatory until the limitation gets lifted? Also, I would suggest documenting the fact it could take a while for wildcarded args.

Makes sense, I'll do the above for the next version of this PR.

just FYI, I'm fine with the remaining changes. Of course, I'll take another look at the last spin, when available.

[atenart]

I have another proposal for the previous comments. The debug build takes forever but the release one is much faster (it's still super slow). At the same time what takes so long is the retrieval of the k(ret)probe list, the tp one is only a matter of a few seconds.

What about:

• Still reworking the help.
• Removing kretprobe from the output when no type is given. It's the same list as kprobe anyway and it's quite a niche use.

With that (above suggestion + release built), retis inspect -p takes 20s on my laptop.

[vlrpl]

I have another proposal for the previous comments. The debug build takes forever but the release one is much faster (it's still super slow). At the same time what takes so long is the retrieval of the k(ret)probe list, the tp one is only a matter of a few seconds.

What about:

* Still reworking the help.

* Removing `kretprobe` from the output when no type is given. It's the same list as `kprobe` anyway and it's quite a niche use.

With that (above suggestion + release built), retis inspect -p takes 20s on my laptop.

yes, it's much better for release. About your proposal, it makes perfect sense.

[atenart]

Rebased on main to fix CI issues & resolve a merge conflict.