Writing character devices is a common way to start writing kernel code,
especially because of the book "Linux Device Drivers", which is still
one of the best resources to learn about Linux kernel programming. To
allow an easier entry into Rust kernel programming specifically, this
series adds abstractions for these kinds of devices to the Rust API.

I also included a sample that demonstrates how to use these abstractions
to create the simplest example from LDD3, the "scull" device.

I'm also aware of the patch series about misc devices that was sent
recently. I think these are both valuable additions to the Rust API, and
could even be combined in some way, in which case the file operations
abstractions in both series should probably be separated and
generalized. But I'm still sending this series as it is, because it is
my first ever patch and I could use some feedback on my approach.

This series depends on the File abstraction patch [1] and the
Opaque::try_ffi_init patch [2], however, the latter is such a small
change that it could easily be included in this series if necessary.

Link: https://lore.kernel.org/all/20240915-alice-file-v10-3-88484f7a3dcf@google.com/ [1]
Link: https://lore.kernel.org/all/20241001-b4-miscdevice-v2-1-330d760041fa@google.com/ [2]
Signed-off-by: Josef Zoller <josef@walterzollerpiano.com>
---
Josef Zoller (3):
      rust: char_dev: add character device abstraction
      rust: macros: add IoctlCommand derive macro
      samples: rust: add character device sample

 rust/bindings/bindings_helper.h |   1 +
 rust/helpers/fs.c               |  16 +
 rust/kernel/char_dev.rs         | 976 ++++++++++++++++++++++++++++++++++++++++
 rust/kernel/init/macros.rs      |  10 +-
 rust/kernel/ioctl.rs            | 236 +++++++++-
 rust/kernel/lib.rs              |   1 +
 rust/kernel/prelude.rs          |   2 +-
 rust/macros/ioctl_cmd.rs        | 202 +++++++++
 rust/macros/lib.rs              |  21 +
 samples/rust/Kconfig            |  10 +
 samples/rust/Makefile           |   1 +
 samples/rust/rust_char_dev.rs   | 506 +++++++++++++++++++++
 12 files changed, 1977 insertions(+), 5 deletions(-)
---
base-commit: ce1c54fdff7c4556b08f5b875a331d8952e8b6b7
change-id: 20241011-rust-char-dev-f82eb3e29899
prerequisite-patch-id: be636dd988fbd1f993df5fe7cd10eabfadd319b2
prerequisite-patch-id: 478b4285f3752e64043d2e3b5ccd786ef039f659

Best regards,
-- 
Josef Zoller <josef@walterzollerpiano.com>

On Fri, Oct 11, 2024 at 08:55:41PM +0200, Josef Zoller wrote:
> Writing character devices is a common way to start writing kernel code,
> especially because of the book "Linux Device Drivers", which is still
> one of the best resources to learn about Linux kernel programming. To
> allow an easier entry into Rust kernel programming specifically, this
> series adds abstractions for these kinds of devices to the Rust API.

I understand this, but if at all possible, I would prefer that people
stick to using the misc char device interface instead.  It's much
simpler and integrates better into the overall system (handles sysfs for
you automatically, etc.)

I've already merged the misc device rust bindings into my tree, so why
not just stick with them?

> I also included a sample that demonstrates how to use these abstractions
> to create the simplest example from LDD3, the "scull" device.

This is great, but why not just provide the scull example using misc
device?

> I'm also aware of the patch series about misc devices that was sent
> recently. I think these are both valuable additions to the Rust API, and
> could even be combined in some way, in which case the file operations
> abstractions in both series should probably be separated and
> generalized. But I'm still sending this series as it is, because it is
> my first ever patch and I could use some feedback on my approach.

That's great, but I'd prefer to stick with the misc code for now until
someone really really really proves that they want a "raw" char
interface.

thanks,

greg k-h

On 12.10.24 09:29, Greg Kroah-Hartman wrote:
> On Fri, Oct 11, 2024 at 08:55:41PM +0200, Josef Zoller wrote:
>> Writing character devices is a common way to start writing kernel code,
>> especially because of the book "Linux Device Drivers", which is still
>> one of the best resources to learn about Linux kernel programming. To
>> allow an easier entry into Rust kernel programming specifically, this
>> series adds abstractions for these kinds of devices to the Rust API.
>
> I understand this, but if at all possible, I would prefer that people
> stick to using the misc char device interface instead.  It's much
> simpler and integrates better into the overall system (handles sysfs for
> you automatically, etc.)
>
> I've already merged the misc device rust bindings into my tree, so why
> not just stick with them?

Aaaah, I should probably have done some proper 'market research' before
just blindly diving into and implementing this. So, if I understand you
correctly, you're saying that only very niche use cases would benefit
from being implemented as a raw char device, and that the misc device
interface is the way to go for most cases?

>> I also included a sample that demonstrates how to use these abstractions
>> to create the simplest example from LDD3, the "scull" device.
>
> This is great, but why not just provide the scull example using misc
> device?

I don't remember seeing a misc device implementation in the book. Are
you just saying that the scull device could be easily implemented as a
misc device instead, or am I missing something?

>> I'm also aware of the patch series about misc devices that was sent
>> recently. I think these are both valuable additions to the Rust API, and
>> could even be combined in some way, in which case the file operations
>> abstractions in both series should probably be separated and
>> generalized. But I'm still sending this series as it is, because it is
>> my first ever patch and I could use some feedback on my approach.
>
> That's great, but I'd prefer to stick with the misc code for now until
> someone really really really proves that they want a "raw" char
> interface.

Fair enough. So, it seems like I should probably just drop this series,
right? I will probably still address the other feedback you gave me in
a second version, but putting much more effort into this series seems
like a waste of time now.

Anyway, thanks for the honest and early feedback! I could have easily
spent much more time on this series without knowing that it's not what
you're looking for.

Cheers,
Josef