Rust: how to implement file_operations for a misc device?
Hello, brand-new kernel newbie here. I'm interested in the Rust side of the kernel. To get acquainted, I'm following the Linux Driver Development book, 3rd edition, also integrating it with modern documentation and best practices (or at least I hope so). I'm developing the scull module on top of the `kernel::miscdevice::MiscDevice` trait. Where I'm stuck at is the lack of the `kernel::file::Operations` trait [1], that most online resources refer to. I need such trait to implement read and write operations for the misc device. AFAIU, this trait used to exist but it's no longer in the mainline codebase [2]. Also, `kernel::miscdevice::MiscdeviceVTable` is private inside the miscdevice module, so there's no way I can somehow extend it. Is there any workaround for what I want to achieve, or is ioctl the only allowed interface to misc devices in Rust? Thank you, Fabio. [^1]: https://rust-for-linux.github.io/docs/kernel/file/trait.Operations.html [^2]: https://rust.docs.kernel.org/kernel/fs/index.html
On Tue, Sep 23, 2025 at 06:47:25PM +0200, Fabio wrote:
Hello,
brand-new kernel newbie here. I'm interested in the Rust side of the kernel. To get acquainted, I'm following the Linux Driver Development book, 3rd edition, also integrating it with modern documentation and best practices (or at least I hope so).
I'm developing the scull module on top of the `kernel::miscdevice::MiscDevice` trait. Where I'm stuck at is the lack of the `kernel::file::Operations` trait [1], that most online resources refer to. I need such trait to implement read and write operations for the misc device. AFAIU, this trait used to exist but it's no longer in the mainline codebase [2]. Also, `kernel::miscdevice::MiscdeviceVTable` is private inside the miscdevice module, so there's no way I can somehow extend it.
Is there any workaround for what I want to achieve, or is ioctl the only allowed interface to misc devices in Rust?
Please see the rust sample misc driver that is right now in linux-next, it shows how to use the read and write iter functions, which should be all that you need. Specifically look at commit e5b0d7da941a ("samples: rust_misc_device: Expand the sample to support read()ing from userspace"), which shows how this can be done. Yes, this is a bit different than the traditional "read/write" callbacks, as documented in the device driver's book, but things have moved on in the decades since we wrote that :) The changes for this will be showing up in the next kernel release (i.e. 6.18). hope this helps, greg k-h
Hi, Do I need to call mutex_destroy in a failed probe exit, or in the remove module function, if the mutex is located in memory allocated with devm_kzalloc and family? Like: static int mychip_i2c_probe(struct i2c_client *client) { struct chip *chip; int ret; chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) return -ENOMEM; mutex_init(&chip->lock); i2c_set_clientdata(client, chip); /* Do my chip stuf */ return ret; probe_fail: mutex_destroy(&chip->lock); return ret; } I understand that mutex_destroy will only invalidate the memory, but as I am freeing this is not necessary? Thanks Lucas Tanure
On Fri, Nov 14, 2025 at 10:42 AM Lucas Tanure <tanure@linux.com> wrote:
Hi,
Do I need to call mutex_destroy in a failed probe exit, or in the remove module function, if the mutex is located in memory allocated with devm_kzalloc and family? Like: static int mychip_i2c_probe(struct i2c_client *client) { struct chip *chip; int ret;
chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) return -ENOMEM;
mutex_init(&chip->lock); i2c_set_clientdata(client, chip);
/* Do my chip stuf */
return ret;
probe_fail: mutex_destroy(&chip->lock); return ret; }
I understand that mutex_destroy will only invalidate the memory, but as I am freeing this is not necessary?
Thanks Lucas Tanure
Hi, Could someone help shed some light on this? Should I do mutex_destroy on a mutex that is inside a memory that's about to be freed? thanks
On Fri, Nov 14, 2025 at 10:42 AM Lucas Tanure <tanure@linux.com> wrote:
I understand that mutex_destroy will only invalidate the memory, but as I am freeing this is not necessary?
My knowledge is also limited, but having taken a look, devm_mutex_init seems to handle registering mutexes in the subsystem and conditionally no-op it if lock debugging is off (since the init and destroy is just instrumenting the lock for debugging). Hope this helps and if anyone would like to correct me that's also welcome. Raka
Since you're using devm_kzalloc, why not simply use devm_mutex_init and not worry about it? Then you can remove your explicit mutex_destroy call. ________________________________________ From: Lucas Tanure <tanure@linux.com> Sent: Friday, November 14, 2025 2:42 AM To: kernelnewbies <kernelnewbies@kernelnewbies.org> Subject: Simple mutex_destroy question Hi, Do I need to call mutex_destroy in a failed probe exit, or in the remove module function, if the mutex is located in memory allocated with devm_kzalloc and family? Like: static int mychip_i2c_probe(struct i2c_client *client) { struct chip *chip; int ret; chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) return -ENOMEM; mutex_init(&chip->lock); i2c_set_clientdata(client, chip); /* Do my chip stuf */ return ret; probe_fail: mutex_destroy(&chip->lock); return ret; } I understand that mutex_destroy will only invalidate the memory, but as I am freeing this is not necessary? Thanks Lucas Tanure _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Nov 19, 2025 at 4:27 PM Billie Alsup (balsup) <balsup@cisco.com> wrote:
Since you're using devm_kzalloc, why not simply use devm_mutex_init and not worry about it? Then you can remove your explicit mutex_destroy call.
I am developing drivers for Android 13 with kernel 5.10/5.4, which doesn't have devm_mutex_init. So, mutex_destroy is only needed for debugging locks? I see a few drivers don't have this call in their remove functions or in fail probe paths.
________________________________________ From: Lucas Tanure <tanure@linux.com> Sent: Friday, November 14, 2025 2:42 AM To: kernelnewbies <kernelnewbies@kernelnewbies.org> Subject: Simple mutex_destroy question
Hi,
Do I need to call mutex_destroy in a failed probe exit, or in the remove module function, if the mutex is located in memory allocated with devm_kzalloc and family? Like: static int mychip_i2c_probe(struct i2c_client *client) { struct chip *chip; int ret;
chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) return -ENOMEM;
mutex_init(&chip->lock); i2c_set_clientdata(client, chip);
/* Do my chip stuf */
return ret;
probe_fail: mutex_destroy(&chip->lock); return ret; }
I understand that mutex_destroy will only invalidate the memory, but as I am freeing this is not necessary?
Thanks Lucas Tanure
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, Nov 20, 2025 at 10:27:06AM +0000, Lucas Tanure wrote:
On Wed, Nov 19, 2025 at 4:27 PM Billie Alsup (balsup) <balsup@cisco.com> wrote:
Since you're using devm_kzalloc, why not simply use devm_mutex_init and not worry about it? Then you can remove your explicit mutex_destroy call.
I am developing drivers for Android 13 with kernel 5.10/5.4, which doesn't have devm_mutex_init.
No new devices should be shipping with Android13 as it is about to go end-of-life, so please do NOT target these old kernels. Do your development on the latest kernel release, get your changes upstream, and then, if you need to apply them to a device-specific kernel, backport it to that older kernel. That way is much simpler and easier and will save you time.
So, mutex_destroy is only needed for debugging locks? I see a few drivers don't have this call in their remove functions or in fail probe paths.
Then those are probably bugs that should be fixed up. thanks, greg k-h
participants (5)
-
Billie Alsup (balsup) -
Fabio -
Greg KH -
Lucas Tanure -
Raka Gunarto