From danielcroitoro at gmail.com Mon Sep 1 13:39:23 2025 From: danielcroitoro at gmail.com (Daniel) Date: Mon, 1 Sep 2025 20:39:23 +0300 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From torin at tcarey.uk Sun Sep 7 14:57:02 2025 From: torin at tcarey.uk (Torin Carey) Date: Sun, 07 Sep 2025 18:57:02 +0000 Subject: Existing patches of similar content Message-ID: Hi KernelNewbies, Apologies if this is a stupid question. I was finishing up on a patch to add a new (fairly small) feature to an existing driver. While looking at the archives for the relevant mailing list, I noticed another contributor had submitted a patch to add the exact same feature just under a year ago, but the thread seems to have gone stale. I believe there are some bits that were missing from this patch in terms of correctness. What's the usual etiquette to approach this situation? I could: 1. submit my patch for review anyway; or 2. resurrect this thread providing a review for it along with the additions I think might be necessary; or 3. a combination of both? --- Torin From alison.schofield at intel.com Mon Sep 8 17:48:27 2025 From: alison.schofield at intel.com (Alison Schofield) Date: Mon, 8 Sep 2025 14:48:27 -0700 Subject: Existing patches of similar content In-Reply-To: References: Message-ID: On Sun, Sep 07, 2025 at 06:57:02PM +0000, Torin Carey wrote: > Hi KernelNewbies, > > Apologies if this is a stupid question. > > I was finishing up on a patch to add a new (fairly small) feature to an existing driver. While looking at the archives for the relevant mailing list, I noticed another contributor had submitted a patch to add the exact same feature just under a year ago, but the thread seems to have gone stale. I believe there are some bits that were missing from this patch in terms of correctness. > > What's the usual etiquette to approach this situation? I could: > 1. submit my patch for review anyway; or > 2. resurrect this thread providing a review for it along with the additions I think might be necessary; or > 3. a combination of both? Kudo's to you for asking and for looking through the lore history of your subsystem and finding the history of this feature. There's a lot of variability in lore mailing lists, reviewers, and maintainers responsiveness, so to be generic, I'll suggest your #2 option. Reply to the patch, show what you'd like to change, and see what happens. Maybe you breathe new life into it, the original author picks up your changes, and the feature moves forward. Maybe the original author acknowledges your changes and asks you to pick it up and carry it forward. Maybe crickets, in which case you can submit a new patch, probably with a tag 'Originally-by:' or 'Co-developed-by'. BTW if you do pick it up, make sure to address any concerns raised with the original patch. Good Luck, Alison > > --- > Torin > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies From torin at tcarey.uk Mon Sep 15 08:41:06 2025 From: torin at tcarey.uk (Torin Carey) Date: Mon, 15 Sep 2025 12:41:06 +0000 Subject: Existing patches of similar content In-Reply-To: References: Message-ID: On Mon, Sep 08, 2025 at 02:48:27PM -0700, Alison Schofield wrote: > Kudo's to you for asking and for looking through the lore history of your > subsystem and finding the history of this feature. > > There's a lot of variability in lore mailing lists, reviewers, and maintainers > responsiveness, so to be generic, I'll suggest your #2 option. Reply to the > patch, show what you'd like to change, and see what happens. > > Maybe you breathe new life into it, the original author picks up your changes, > and the feature moves forward. > > Maybe the original author acknowledges your changes and asks you to pick it up > and carry it forward. > > Maybe crickets, in which case you can submit a new patch, probably with a tag > 'Originally-by:' or 'Co-developed-by'. > > BTW if you do pick it up, make sure to address any concerns raised with the > original patch. > > Good Luck, > Alison Hi Alison, Thanks for the advice! In that case I'll work on putting some review comments together and see if it goes anywhere. If not I'll consider publishing my own patch. The original patch didn't seem to receive any concerns, but hopefully some renewal to it could get some more attention on it. Thanks, Torin From development at redaril.me Tue Sep 23 12:47:25 2025 From: development at redaril.me (Fabio) Date: Tue, 23 Sep 2025 18:47:25 +0200 Subject: Rust: how to implement file_operations for a misc device? Message-ID: <240f21b8-6d0c-4ce0-8dbb-2eea3c6d6b1d@redaril.me> 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 From greg at kroah.com Wed Sep 24 06:27:30 2025 From: greg at kroah.com (Greg KH) Date: Wed, 24 Sep 2025 12:27:30 +0200 Subject: Rust: how to implement file_operations for a misc device? In-Reply-To: <240f21b8-6d0c-4ce0-8dbb-2eea3c6d6b1d@redaril.me> References: <240f21b8-6d0c-4ce0-8dbb-2eea3c6d6b1d@redaril.me> Message-ID: <2025092445-editor-wobbling-1f26@gregkh> 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