Support clone opens in the CharDevice glue #1
Loading…
Reference in a new issue
No description provided.
Delete branch "drm-r0"
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?
Needed by the Rust DRM core (illumos-drm, WI-452 R0). A DRM device exposes
card0andrenderD128minors and must hand everyopen(2)its own minor so per-file state can be tracked, the same clone-open pattern gfx-drm'sdrm_sunmod.cuses.CharDevice::clone_open: theopen(9E)glue lets the driver return a new minor and writes it back throughdevp. The default keeps existing drivers unchanged.dev_tlimit that bounds clone minors.illumos-drm pins this branch (
f36d47958e) until it is onmain.Three commits added for illumos-drm R1 (GEM mmap), same style as
clone_open:94680b671cSupport devmap(9E) in the CharDevice glue:CharDevice::devmap(minor, DevmapHandle, off, len, model, ctx) -> Result<usize, Errno>(defaultENXIO) andmodule! { driver: X, ops: [char, devmap] }, which installs the glue asdevmap(9E),ddi_devmap_segmap(9F)assegmap(9E)and setsD_DEVMAP.ops: [char]is unchanged. The glue accepts a validated length up to the end of the page holding the last requested byte (mmap(2)passes the length unrounded) and refuses anything longer; a negative offset isEINVAL.bfc7ff7b2aRefuse a devmap(9E) length of zero or of a partial page (devmap_setup(9F)advances only by the validated length, so 0 would loop for ever).77df4ce177Describe CharDevice::devmap in the design document (section 5.2), including two facts fromseg_dev.c:devmap_setup(9F)reports every driver error asENXIO, and a handle can be freed after a successfuldevmap(9E)without anydevmap_map/devmap_unmapcallback.illumos-drm pins
bfc7ff7b2ae520e0c5592ae4e9780e22564bc070; its R1 pull request (illumos/illumos-drm#2, stacked on illumos/illumos-drm#1) was tested with this revision on oibldofgate: mmap, fork, partial munmap and the refault experiment through these entry points, all passing.