gen7_append_oa_reports(9)
π gen7_append_oa_reports β like, the whole manual page, bestie
okay so this is from the Kernel API Manual, section 9 (kernel dev docs, iykyk), and the star of the show is gen7_append_oa_reports. Buckle up π
β¨ NAME β¨
gen7_append_oa_reports β literally copies all the buffered OA reports into the userspace read() buffer. that's it, that's the job π«Ά
πΈ SYNOPSIS πΈ
int gen7_append_oa_reports (struct i915_perf_stream *stream , char
__user *buf , size_t count , size_t *offset );
look at her go π she returns an int, she takes an i915_perf_stream, she takes a user buffer, she takes a count, she takes an offset pointer. four args, no cap.
π¦ ARGUMENTS π¦
streamβ an i915-perf stream that was opened for OA metrics. the whole reason we're here πbufβ the destination buffer, handed to us by userspace. respect her, she's user memory π«‘countβ how many bytes userspace wants to read. the vibe check for how much room we get.offsetβ (inout) the current position for writing intobuf. it goes in, and it comes out changed, hence "inout", hence the drama β¨
π§ DESCRIPTION π§
So here's the thing bestie, and it's kinda important π Notably, any error condition that results in a short read β that's -ENOSPC or -EFAULT β will be returned even though one or more records may have already been successfully copied. yup. the copy happened, the error still comes back, both things are true, we contain multitudes π
In that case it's up to the caller to decide if the error should be squashed before returning to userspace. caller's problem now, not ours. periodt π
β NOTE β
reports are consumed from the head, and appended to the tail, so the tailβ¦ chases the head?? π likeβ¦
If you think that's mad and back-to-front you're not alone, but this follows the Gen PRM naming convention.
fr fr, we all think it's weird, the PRM said so, we don't make the rules (we literally do not make the rules) π
π₯ RETURN π₯
0on success π- a negative error code on failure π
π SEE ALSO π
Kernel file ./drivers/gpu/drm/i915/i915_perf.c and, like, the entire extended universe of OA lore:
i915 Perf Overview(9)i915 Perf History and Comparison with Core Perf(9)OA Tail Pointer Race(9)struct perf_open_properties(9)oa_buffer_check_unlocked(9)append_oa_status(9)append_oa_sample(9)gen8_append_oa_reports(9)gen8_oa_read(9)gen7_oa_read(9)i915_oa_wait_unlocked(9)i915_oa_poll_wait(9)i915_oa_read(9)oa_get_render_ctx_id(9)oa_put_render_ctx_id(9)i915_oa_stream_enable(9)i915_oa_stream_disable(9)i915_oa_stream_init(9)i915_perf_read(9)i915_perf_poll_locked(9)i915_perf_poll(9)i915_perf_enable_locked(9)i915_perf_disable_locked(9)i915_perf_ioctl_locked(9)i915_perf_ioctl(9)i915_perf_destroy_locked(9)i915_perf_release(9)i915_perf_open_ioctl_locked(9)read_properties_unlocked(9)i915_perf_open_ioctl(9)i915_perf_register(9)i915_perf_unregister(9)i915_perf_add_config_ioctl(9)i915_perf_remove_config_ioctl(9)i915_perf_init(9)i915_perf_fini(9)i915_perf_ioctl_version(9)
that's the whole page babes, every flag, every arg, every cross-reference, no skips, no cap π
mwah π β sourced from ./drivers/gpu/drm/i915, version dated October 2026, page name gen7_append_oa_reports(9). stan her, she's iconic πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms