Support per-device context for `chrdev`

[danobi]

Currently, miscdev::Registration::new and miscdev::Registration::new_pinned both support taking a context to be passed to the FileOpener::open trait method. We'll take it on faith it's useful (IMO it is).

chrdev does not have this support yet. I think it'd make sense to add a context param to chrdev::Registration::register (as opposed to new and new_pinned) b/c the same chrdev::Registration can be used to register multiple cdevs (as opposed to miscdev which can only register one).

[danobi]

I've taken a look at implementing this feature but it's currently made tricky b/c of #207. The linked PR (effectively) made chrdev::Cdev hold struct cdev * instead of struct cdev. This is a problem because we cannot upcast a pointer (struct cdev *) to chrdev::Cdev as you would be able to with the actual structure.

I've racked my brain for a bit but I can't think of any tricks from rust side to derive a context value without a container_of upcast.

I'm considering sending out a RFC to lkml about adding a void *private field to struct cdev b/c the struct is managed by a kobject and the use-after-free issue ought to be an issue for a lot of other drivers. Having an extra private field ought to solve our problem here.

[danobi]

I've sent out an RFC: https://lore.kernel.org/lkml/cover.1641185192.git.dxu@dxuuu.xyz/

[wedsonaf]

Currently, miscdev::Registration::new and miscdev::Registration::new_pinned both support taking a context to be passed to the FileOpener::open trait method. We'll take it on faith it's useful (IMO it is).

Some evidence beyond faith of the usefulness of a context: the Binder code uses it (https://github.com/Rust-for-Linux/linux/blob/rust/drivers/android/process.rs#L810) to hold some state that is shared by all files that share a device. It isn't a global because we can have more than one device (each with several files), and globals should generally be avoided anyway.

[wedsonaf]

I've taken a look at implementing this feature but it's currently made tricky b/c of #207. The linked PR (effectively) made chrdev::Cdev hold struct cdev * instead of struct cdev. This is a problem because we cannot upcast a pointer (struct cdev *) to chrdev::Cdev as you would be able to with the actual structure.

What do you need this for?

The upstream maintainer of chrdev advised us not to expose this yet because he feels new character devices should just use miscdev.

[danobi]

I've taken a look at implementing this feature but it's currently made tricky b/c of #207. The linked PR (effectively) made chrdev::Cdev hold struct cdev * instead of struct cdev. This is a problem because we cannot upcast a pointer (struct cdev *) to chrdev::Cdev as you would be able to with the actual structure.

What do you need this for?

I'm rewriting some of the examples from LDD3 in rust as a fun exercise. Thought I could shake out a few bugs / missing features in rust-for-linux along the way too. LDD3 uses cdev so I thought I'd stick to the original recipe.

The upstream maintainer of chrdev advised us not to expose this yet because he feels new character devices should just use miscdev.

Oh, in that case I'll just use miscdev. Didn't know they were interchangeable.