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

[Lee Jones]

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 [李琼斯]