Rust: how to implement file_operations for a misc device?

Rust: how to implement file_operations for a misc device?

[Fabio]

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



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Rust: how to implement file_operations for a misc device?

[Greg KH]

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Simple mutex_destroy question

[Lucas Tanure]

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

Re: Simple mutex_destroy question

[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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Simple mutex_destroy question

[Raka Gunarto]

> 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Simple mutex_destroy question

[Billie Alsup (balsup)]

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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Simple mutex_destroy question

[Lucas Tanure]

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Simple mutex_destroy question

[Greg KH]

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies