linux-kernel - Re: [PATCH v5 0/4] rust: miscdevice: Provide sample driver using the new MiscDevice bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241206220609.GA6126@google.com>
Date: Fri, 6 Dec 2024 22:06:09 +0000
From: Lee Jones <lee@...nel.org>
To: Danilo Krummrich <dakr@...nel.org>
Cc: linux-kernel@...r.kernel.org, arnd@...db.de, gregkh@...uxfoundation.org,
	ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com,
	gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
	a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v5 0/4] rust: miscdevice: Provide sample driver using the
 new MiscDevice bindings

On Fri, 06 Dec 2024, Danilo Krummrich wrote:

> On Fri, Dec 06, 2024 at 04:49:18PM +0000, Lee Jones wrote:
> > On Fri, 06 Dec 2024, Danilo Krummrich wrote:
> > > > > Also, there was a comment about how we can make use of the `dev_*` macros.
> > > > > 
> > > > > I really think we should fix those before we land a sample driver. It's gonna
> > > > > be hard to explain people later on that they shouldn't do what the example
> > > > > does...
> > > > 
> > > > We're authoring the sample based on what is available at the moment.
> > > 
> > > Well, for this I have to disagree, not being able to use the `dev_*` macros is
> > > simply meaning that the abstraction is incomplete (in this aspect).
> > > 
> > > I don't see the need to land a sample driver that tells the user to do the wrong
> > > thing, i.e. use the `pr_*` macros.
> > > 
> > > As Alice mentioned, you can get the miscdevice pointer from the file private
> > > data in open() and then make it accessible in the other fops hooks. If we go for
> > > this solution it will change the callbacks of `MiscDevice` and maybe even some
> > > other architectural aspects.
> > > 
> > > This needs to be addressed first.
> > 
> > The issue about ever growing dependencies _can_ be that authors have
> > other priorities and are slow to turn things around, which may end up
> > with nothing being accepted and contributors getting frustrated.
> 
> I would share your argumentation if
> 
> 1) we'd talk about a real driver, where people are actually waiting for,
> 2) it'd be about a new feature, performance improvement, etc.
> 
> What we have here is different:
> 
> You wrote a sample implementation for a new and just landed abstraction that
> reveals a shortcoming. (Which is great, because it means the sample already
> served an important purpose.)
> 
> IMHO, the consequence should not be to merge the sample as is anyways, because
> another purpose of the sample implementation is to tell people "look, this is
> exactly how it should look like, please do it the same way".
> 
> Instead, we should fix the shortcoming, adjust the sample implementation and
> merge it then.
> 
> Just to make it clear, for a real driver I think it would be reasonable to just
> go ahead, but for a sample that should educate, we should fix things first.

Provided that we stay within certain tolerances, I don't see any of
what you've said as particularly unreasonable.  I'll have an out-of-band
chat with Alice on Monday with a view to conjuring up a game plan.

-- 
Lee Jones [李琼斯]