Feature Request: Support logging `bpf_get_current_comm()` output as a human-readable string

[gauravakto]

Context: I am completely new to rust. Trying to port an existing BCC eBPF implementation to aya.

Disclosure: Heavily using AI agents to code this with limited understanding.

Summary

There is no way to log a process name (comm) from a BPF program using aya-log-ebpf. This is one of the most common things you want to include in a BPF log line — "which process triggered this event?" — and currently there's no supported path to do it.

Background

bpf_get_current_comm() is a standard BPF helper that returns the current process name as a [u8; 16] null-terminated byte array. It is the BPF equivalent of reading /proc/<pid>/comm. Nearly every BPF observability tool logs this.

In aya, the natural thing to write is:

use aya_ebpf::helpers::bpf_get_current_comm;
use aya_log_ebpf::info;

let comm = bpf_get_current_comm().unwrap_or([0u8; 16]);
info!(ctx, "connect() called by process={} pid={}", comm, pid);

This does not work.

What happens today

aya-log-parser only recognises these format specifiers (source):

Specifier	Meaning
{}	Default
{:x} / {:p}	Lower hex
{:X}	Upper hex
{:i}	IP address
{:mac}	Lower MAC
{:MAC}	Upper MAC

For [u8; 16]:

Versions

Using latest aya: https://docs.rs/aya/0.14.0/aya/

• aya-log 0.2.1
• aya-log-ebpf 0.1.0
• aya-log-parser 0.1.13
• `aya-log-common 0.1.15

[gmreads]

I have created a small PR for this as well.

#1623

completely AI coded. Apologies if this causes noise.

Also @vadorovsky , I saw your talk on youtube berlin Rust and tell 3 years ago.

Full BPF-CORE support is still missing, have followed the thread recently where your pre-RFC was accepted by rust lang. Congratulations really excited to see what comes out of it.
rust-lang/rfcs#3966

I would love to help contribute in any way I can.

[vadorovsky]

I have created a small PR for this as well.

#1623

completely AI coded. Apologies if this causes noise.

Using AI in Aya is OK (we, maintainers, do it too), just take some time to fully understand the output, and ensure the quality. The last thing recently becomes less of a problem though, from my experience Qwen3.6 and gpt-5.5 are pretty good with code quality and don't produce "slop". I will do a proper review of your PR later, but from the first glance it looks good, aside from CI failures (would be great if you can have a look before I do).

Also @vadorovsky , I saw your talk on youtube berlin Rust and tell 3 years ago.

Full BPF-CORE support is still missing, have followed the thread recently where your pre-RFC was accepted by rust lang. Congratulations really excited to see what comes out of it. rust-lang/rfcs#3966

I would love to help contribute in any way I can.

Thanks! In terms of coding, it's not really splitable work, so I will take care of the implementation in Rust entirely. That said, I will definitely need some help with testing and gathering examples, so once I have working implementation in Rust nightly, we can talk about it.

[gmreads]

Sure thanks for the confirmation on direction, I was not quite sure why such a simple thing doesn't exist in the logging library.
I was afraid AI may not be able to detect nuanced reason, maybe this {:s} doesn't exist due to some kernel/ebpf verifier limitation.
( I too have very limited experience in this area).

Yes I am looking into fixing the CI errors and following the contributing.md guide.