drm-core: a driver ioctl matches its number in any direction, as in Linux #19
Loading…
Reference in a new issue
No description provided.
Delete branch "x230-driver-ioctl-direction"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Driver-private commands matched an entry by value, or by group, number and direction with another size. Linux's
drm_ioctl()indexes the driver's table by number and copies the argument in the directions both commands have, and drivers rely on that: i915 lists onlyDRM_IOCTL_I915_GEM_EXECBUFFER2_WR(_IOWR), while Mesa's crocus and iris submit every batch withDRM_IOCTL_I915_GEM_EXECBUFFER2(_IOW, the same number).On a ThinkPad X230 (HD 4000) with i915n attached, crocus created its context (
Mesa Intel(R) HD Graphics 4000 (IVB GT2), GL 4.2) and aborted in_crocus_batch_flushat the first submission:lookup_driver()now falls back to the first entry with the same group and number in any direction, after the exact value and after the same direction with another size, so a table listing several forms keeps each.SizePlanalready copies in and out only in the directions both commands have, so an_IOWcall of the_IOWRentry is copied in and not back, as in Linux. The core's own and the mode-setting commands keep their stricter rule (another direction is ENOTTY), which the guest tests (drm_r0_test,drm_g6_test) check. Module docs updated;driver_rangetest updated anddriver_write_only_form_of_a_read_write_entryadded.Checks (Mac, 1.97.1):
cargo check --locked --workspace --target x86_64-unknown-illumos, clippy-D warnings(same target), fmt,cargo test -p drm-core -p drm-uapi -p drm-facade(161 drm-core),cargo test -p virtio_gpu --no-default-features.Tested on the X230 (branch
x230-test, crocus over GBM/EGL surfaceless onrenderD128): glClear + readback 65536/65536 pixels right, 600 clear/readback frames at 3473 frames/s; GLSL 4.20 shaders, full-screen quad with four checked pixels, 2000 frames of 64 triangles withglFinisheach at 2847 frames/s; four concurrent clients x 20000 frames (about 100k requests), no GL error, no kernel warning, no hang; 621 MSI interrupts claimed during a 600-frame run.Driver-private commands matched an entry by value, or by group, number and direction with another size. Linux's drm_ioctl() indexes the driver's table by number and copies the argument in the directions both commands have, and drivers rely on that: i915 lists only DRM_IOCTL_I915_GEM_EXECBUFFER2_WR (_IOWR), while Mesa's crocus and iris submit every batch with DRM_IOCTL_I915_GEM_EXECBUFFER2 (_IOW, the same number). On a ThinkPad X230 (HD 4000) with i915n, crocus created its context and then aborted at the first batch: the submission was ENOTTY (truss: ioctl(6, _IOWN('d', 105, 64)) Err#25 ENOTTY). lookup_driver() now falls back to the first entry with the same group and number in any direction, after the exact value and after the same direction with another size, so that a table listing several forms keeps each. SizePlan already copies in and out only in the directions both commands have, so an _IOW call of the _IOWR entry is copied in and not back, as in Linux. The core's own commands and the mode-setting commands keep their stricter rule (another direction is ENOTTY), which the guest tests check.