Re: [PATCH v3 3/5] samples: rust: Provide example using the new Rust MiscDevice abstraction

Greg Kroah-Hartman
2024-12-06T07:03:37Z

On Fri, Dec 06, 2024 at 07:52:46AM +0100, Arnd Bergmann wrote:
> On Fri, Dec 6, 2024, at 07:49, Greg KH wrote:
> > On Thu, Dec 05, 2024 at 04:25:20PM +0000, Lee Jones wrote:
> >> +
> >> +#[vtable]
> >> +impl MiscDevice for RustMiscDevice {
> >> + type Ptr = KBox<Self>;
> >> +
> >> + fn open() -> Result<KBox<Self>> {
> >> + pr_info!("Opening Rust Misc Device Sample\n");
> >> +
> >> + Ok(KBox::new(RustMiscDevice, GFP_KERNEL)?)
> >> + }
> >> +
> >> + fn ioctl(
> >> + _device: <Self::Ptr as kernel::types::ForeignOwnable>::Borrowed<'_>,
> >> + cmd: u32,
> >> + _arg: usize,
> >> + ) -> Result<isize> {
> >> + pr_info!("IOCTLing Rust Misc Device Sample\n");
> >> +
> >> + match cmd {
> >> + RUST_MISC_DEV_HELLO => pr_info!("Hello from the Rust Misc Device\n"),
> >> + _ => {
> >> + pr_err!("IOCTL not recognised: {}\n", cmd);
> >> + return Err(ENOIOCTLCMD);
> >
> > To quote errno.h:
> > These should never be seen by user programs
> >
> > The correct value here is ENOTTY.
> >
> > Yeah, fun stuff. Not intuitive at all, sorry.
>
> That should get handled by vfs_ioctl() converting the
> ENOIOCTLCMD to ENOTTY.

Ah, I always miss that, for some reason I thought that didn't happen
there, but happened in subsystems that did ENOIOCTLCMD for their
sub-ioctl handlers. And yet it's always been that way, nevermind...

Anyway, I always recommend just using ENOTTY to be "safe", the usual way
people get this wrong is using EINVAL.

thanks,

greg k-h