argv[0] usage in print-outs about bpftool HOT 9 CLOSED

Patch on mailing list: https://lore.kernel.org/bpf/[email protected]/t/#u
Patchwork: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

from bpftool.

• [bpf-next] bpftool: Set binary name to "bpftool" in help and version output
  https://git.kernel.org/bpf/bpf-next/c/7e5eb725cf0a

from bpftool.

OK. I see our packages (currently) pull from regular kernel tarballs.

from bpftool.

Hi, thanks! “I don't like that” is hardly a technical argument, but if there's a valid motivation for the change, I don't have any objection. Could you please provide more details about the issue? I don't understand why meson should be affected by bpftool's output. If it needs to parse the version number, have you considered the JSON output (bpftool -j -V), which is more stable, and not based on argv[0]?

If you want argv[0] replaced with bpftool, would you be willing to work on that change? I could submit on your behalf if working with the mailing list is an issue.

from bpftool.

systemd's meson file is calling a completely generic function: https://mesonbuild.com/Reference-manual_functions.html#find_program So yes, another approach to this particular issue could be by patching on systemd side, but to me it seemed to improve bpftool anyway.

The linked pull request contains a simple patch that works.

from bpftool.

Not a fan of updating a program when, yes, it should likely be systemd adjusting here. Also if we do this, I don't see the point in stripping argv[0] from its dirname, we should change it entirely.

This being said, I do agree that having bpftool instead of using the full path would be nicer (having e.g. /usr/lib/linux-tools/5.4.0-126-generic/bpftool on Ubuntu 20.04, due to the linux-tools wrapper, looks weird). I see it's just a matter of changing bin_name = argv[0]; in the source, I'll send a patch at some point.

from bpftool.

There are other interesting quirks that can arise here. For example, programs that support Windows may obviously have Windows' favorite dead weight, .exe, attached to the argv0 on the other side. Or... not, again depending on how you call it. Another possibility is to have multiple versions of the same program installed as "/usr/bin/foo-1.0" and "/usr/bin/foo-2.0", in which case the version output then has the version twice, once in the program name and once following it. Possibly even versions with different granularity.

You can't even solve this by stripping off the dirname.

I think a more generally useful guideline for how to construct the version output is to ask, what's the purpose of the first word of the output? Is it:

• to clarify how to invoke it?
• to pretty-print the program project name?

I'm a believer in option 2, so I don't want the version or help text to ever print out something that's "wrong" for the program project name.

It is, admittedly, easier and more convenient to use argv0 in cases where, for example, the help or version text is printed by shared code used with multiple executables (for example a shell script function in a sourced library file, or a program that does busybox-style adaptation to the name it is called with).

My personal habit is to use argv0 with the dirname stripped off in those cases of shared code, and just not worry about edge cases in parallel renaming, and hardcode a fixed name in all other cases.

from bpftool.

Thanks a lot for the context!

In the case of bpftool, I just think we've never really thought about this in details. It's been using argv[0] since its creation, and we've never really questioned it so far.

Of the two options you stated, clarifying the invocation or pretty-printing the name, I also believe the second is preferable. For the former, tools like which should be used instead. Given that bpftool does not share code with other executables, dropping argv[0] seems the most reasonable way forward. There are plans to run bpftool on Windows in the future, but we can figure out something when the time comes if we feel like we need the .exe.

from bpftool.

Not sure where you pull bpftool from for your packaging. Just for your information, in this repo, I'll sync up and pull the commit next time there's an update on the libbpf mirror (I align bpftool's mirror on it).

from bpftool.