Documentation/userspace-api/ioctl/ioctl-number.rst | 4 ++-- include/uapi/linux/media.h | 4 ++++ samples/rust/rust_misc_device.rs | 14 +++++++------- 3 files changed, 13 insertions(+), 9 deletions(-)
Hello all, The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the range from 0x80 upwards is documented to belong to samples. The samples, however, are currently using these values. Solve the problem by bumping the top of the MC range and the samples allocation by 0x10 as the samples don't require a stable IOCTL interface. since v1: - Improved the commit message in the first patch. - Added a patch to change the IOCTLs also in the Rust sample. Sakari Ailus (3): Documentation: Bump media IOCTL reserved numbers media: uapi: Document IOCTL number assignment samples: rust_misc_device: Bump IOCTL numbers Documentation/userspace-api/ioctl/ioctl-number.rst | 4 ++-- include/uapi/linux/media.h | 4 ++++ samples/rust/rust_misc_device.rs | 14 +++++++------- 3 files changed, 13 insertions(+), 9 deletions(-) -- 2.39.5
Hi Jonathan, Greg, Miguel, others, On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote: > Hello all, > > The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the > range from 0x80 upwards is documented to belong to samples. The samples, > however, are currently using these values. Solve the problem by bumping > the top of the MC range and the samples allocation by 0x10 as the samples > don't require a stable IOCTL interface. Could you comment on this, please? I'd prefer to merge this via the media tree if that's ok. > > since v1: > > - Improved the commit message in the first patch. > > - Added a patch to change the IOCTLs also in the Rust sample. > > Sakari Ailus (3): > Documentation: Bump media IOCTL reserved numbers > media: uapi: Document IOCTL number assignment > samples: rust_misc_device: Bump IOCTL numbers > > Documentation/userspace-api/ioctl/ioctl-number.rst | 4 ++-- > include/uapi/linux/media.h | 4 ++++ > samples/rust/rust_misc_device.rs | 14 +++++++------- > 3 files changed, 13 insertions(+), 9 deletions(-) > -- Kind regards, Sakari Ailus
On Fri, Sep 05, 2025 at 01:25:33PM +0300, Sakari Ailus wrote: > Hi Jonathan, Greg, Miguel, others, > > On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote: > > Hello all, > > > > The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the > > range from 0x80 upwards is documented to belong to samples. The samples, > > however, are currently using these values. Solve the problem by bumping > > the top of the MC range and the samples allocation by 0x10 as the samples > > don't require a stable IOCTL interface. > > Could you comment on this, please? Why not just live with the overlap? What problem is this causing? It's the MC subsystem's "bug" in that it took over an ioctl range that was already documented as being used by something else :) thanks, greg k-h
Hi Greg, On Fri, Sep 05, 2025 at 12:32:45PM +0200, Greg Kroah-Hartman wrote: > On Fri, Sep 05, 2025 at 01:25:33PM +0300, Sakari Ailus wrote: > > Hi Jonathan, Greg, Miguel, others, > > > > On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote: > > > Hello all, > > > > > > The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the > > > range from 0x80 upwards is documented to belong to samples. The samples, > > > however, are currently using these values. Solve the problem by bumping > > > the top of the MC range and the samples allocation by 0x10 as the samples > > > don't require a stable IOCTL interface. > > > > Could you comment on this, please? > > Why not just live with the overlap? What problem is this causing? It's > the MC subsystem's "bug" in that it took over an ioctl range that was > already documented as being used by something else :) I do agree ideally this shouldn't have happened in the first place, but I think it's also cleaner if we can have separate ranges. Pushing samples out a little doesn't look like an issue to me. The set also adds a comment on not adding media IOCTLs beyond the new allocation. -- Kind regards, Sakari Ailus
© 2016 - 2025 Red Hat, Inc.