aya: add guardrails for valid combinations of perf_event type and config fields

[tyrone-wu]

Add guardrails for when setting event type and config for perf_event program. The added PerfEventConfig enum now defines the event type and config of interest.

Idiomatic Rust types are added for:

• perf_hw_id => HardwareEvent
• perf_sw_ids => SoftwareEvent
• perf_hw_cache_id => HwCacheEvent
• perf_hw_cache_op_id => HwCacheOp
• perf_hw_cache_op_result_id => HwCacheResult

The motivation behind this is mainly for the type and config fields of bpf_link_info.perf_event.event (in a separate branch). I plan to use these newly added enums bpf_link_info metadata. https://elixir.bootlin.com/linux/v6.10/source/include/uapi/linux/bpf.h#L6714

One thing to note is that although Breakpoint/PERF_TYPE_BREAKPOINT variant exists, it is not fully implemented at the moment (due to some additional fields need in perf_event_attr like bp_type, etc.). It's only usage currently will be in retrieving link info.

---

I have it named as PerfEventConfig as the moment. I'm not too sure on the naming tho. :/

---

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	7ac81a2
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/670697843cdefa0008877775
😎 Deploy Preview	https://deploy-preview-1038--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mergify]

Hey @alessandrod, this pull request changes the Aya Public API and requires your review.

[tamird]

LGTM

[tamird]

why do we need this repr?

[tyrone-wu]

I had it originally for converting the enum for config (which expects a u64), but I just confirmed that it wouldn't benefit here.

Off topic, but apparently it would only "benefit" when doing https://users.rust-lang.org/t/c-style-enums-reference-conversion/15501 or other wacky mem::transmute stuff.

[mergify]

@tyrone-wu, this pull request is now in conflict and requires a rebase.

[tamird]

Reviewed 1 of 3 files at r1, all commit messages.
Reviewable status: 1 of 3 files reviewed, 4 unresolved discussions (waiting on @alessandrod and @tyrone-wu)

---

-- commits line 2 at r1:
nit: get this down to 50 columns plz (just the subject)

---

aya/src/programs/perf_event.rs line 89 at r1 (raw file):

    /// The total CPU cycles.
    #[doc(alias = "PERF_COUNT_HW_CPU_CYCLES")]
    CpuCycles = perf_hw_id::PERF_COUNT_HW_CPU_CYCLES as isize,

it'd be better to use repr(foo) if it means we can avoid these casts (especially from an unsigned type to this signed type).

---

aya/src/programs/perf_event.rs line 327 at r1 (raw file):

        let (event_type, config) = match perf_type {
            PerfEventConfig::Hardware(hw_event) => (PERF_TYPE_HARDWARE as u32, hw_event as u64),

would it be possible to avoid these as casts? In other words can we align the types we use such that we match the types of these constants? More precisely we should use the type perf_type_id instead of u32 and

[tyrone-wu]

Reviewable status: 1 of 3 files reviewed, 3 unresolved discussions (waiting on @alessandrod and @tamird)

---

-- commits line 2 at r1:

Previously, tamird (Tamir Duberstein) wrote…

nit: get this down to 50 columns plz (just the subject)

👍 👍

---

aya/src/programs/perf_event.rs line 89 at r1 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

it'd be better to use repr(foo) if it means we can avoid these casts (especially from an unsigned type to this signed type).

Correct me if I'm wrong, but I believe casting is unavoidable since they're being coerced from enum type. isize would let the compiler handle its layout, so I don't think it would differ with a different repr since casting happens either way.

---

aya/src/programs/perf_event.rs line 327 at r1 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

would it be possible to avoid these as casts? In other words can we align the types we use such that we match the types of these constants? More precisely we should use the type perf_type_id instead of u32 and

🫡 The PerfEventConfig::Pmu variant not belonging to perf_type_id, but I was sorta able to align it for a single u32 cast.

[tamird]

Reviewed all commit messages.
Reviewable status: 1 of 3 files reviewed, 3 unresolved discussions (waiting on @alessandrod and @tyrone-wu)

---

aya/src/programs/perf_event.rs line 89 at r1 (raw file):

Previously, tyrone-wu (Tyrone Wu) wrote…

Correct me if I'm wrong, but I believe casting is unavoidable since they're being coerced from enum type. isize would let the compiler handle its layout, so I don't think it would differ with a different repr since casting happens either way.

Could we use https://github.com/rust-num/num-derive to derive ToPrimitive on perf_hw_id and then use that instead of these as casts?

[tyrone-wu]

Reviewable status: 1 of 3 files reviewed, 3 unresolved discussions (waiting on @alessandrod and @tamird)

---

aya/src/programs/perf_event.rs line 89 at r1 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

Could we use https://github.com/rust-num/num-derive to derive ToPrimitive on perf_hw_id and then use that instead of these as casts?

I gave num-derive a try , it turns out the functions implemented from ToPrimitive aren't public ☹️. And also, the functions (.to_u32, etc.) return Options. https://docs.rs/num-traits/0.2.19/src/num_traits/cast.rs.html#17

There is https://github.com/illicitonion/num_enum, however, it looks like it just implements From<repr(num)> based on provided #[repr()], which wouldn't be too different from as. :/