[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <654edb82-759e-4845-8698-5257fe69a27c@walterzollerpiano.com>
Date: Sat, 12 Oct 2024 23:14:34 +0200
From: Josef Zoller <josef@...terzollerpiano.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Arnd Bergmann <arnd@...db.de>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 0/3] Character device abstractions for Rust
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
Powered by blists - more mailing lists