You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Description:** Attach a loaded eBPF program to a target interface or attachment point.
92
+
**Description:** Attach a loaded eBPF program to a target interface or attachment point, or to a perf event counter described by `perf_options`. Both forms take three arguments, keeping a uniform call shape across all program types.
92
93
93
94
**Parameters:**
94
-
-`handle`: Program handle returned from `load()`
95
-
-`target`: Target interface name (e.g., "eth0", "lo") or attachment point
96
-
-`flags`: Attachment flags (context-dependent)
95
+
- Standard form:
96
+
-`handle`: Program handle returned from `load()`
97
+
-`target`: Target interface name (e.g., "eth0", "lo") or attachment point
98
+
-`flags`: Attachment flags (context-dependent)
99
+
- Perf event form:
100
+
-`handle`: Program handle returned from `load()`
101
+
-`opts`: `perf_options` value — only `perf_type` and `perf_config` are required; all other fields have defaults
102
+
-`flags`: Reserved (pass `0`)
97
103
98
104
**Return Value:**
99
-
-Returns `0` on success
100
-
-Returns error code on failure
105
+
-Standard form returns `0` on success and an error code on failure
106
+
-Perf event form returns a `PerfAttachment` value with the open counter/link identity and an internal stale-handle token
101
107
102
108
**Examples:**
103
109
```kernelscript
@@ -106,24 +112,33 @@ var result = attach(prog, "eth0", 0)
106
112
if (result != 0) {
107
113
print("Failed to attach program")
108
114
}
115
+
116
+
// Minimal perf attach — all non-perf_type/perf_config fields use defaults:
Use `@perf_event` to attach eBPF programs to hardware or software performance counters. `perf_options` keeps the kernel's tagged `perf_type + perf_config` model, so adding new perf event families does not require flattening everything into one enum. Only `perf_type` and `perf_config` are required; all other fields have sensible defaults. Perf attaches return a first-class attachment value, so if you need the current count in userspace, call `read(att)`:
298
+
299
+
```kernelscript
300
+
// eBPF program fires on every hardware branch-miss sample
# appropriate KernelScript templates with correct context types
441
441
```
442
442
443
+
#### 3.1.3 Perf Event Programs
444
+
445
+
`@perf_event` programs attach eBPF logic to hardware or software performance counters via `perf_event_open(2)`. The eBPF function is invoked for every counter sample; the userspace side controls which counter to monitor through a `perf_options` struct literal passed to the standard 3-argument `attach()`.
For event families with a richer config space, such as `perf_type_hw_cache`, provide the encoded kernel `perf_config` value directly instead of relying on a flattened enum.
534
+
535
+
**Generated C helpers (emitted when `attach(prog, perf_options{...}, flags)` is used):**
3.`close(perf_fd)` — release the kernel perf event
555
+
556
+
**Compiler implementation:**
557
+
- Detects `attach(prog, perf_options_value, flags)` (three-argument form with `perf_options` second arg) and routes to `ks_attach_perf_event`
558
+
- Returns a first-class `PerfAttachment` value for perf attaches so one program can hold multiple live counters
559
+
-`PerfAttachment` carries `perf_fd` plus an internal generation token; `read(attachment)` avoids global attachment-list scans and rejects copied handles after detach
0 commit comments