Message-ID: <ZPiixW6CiR+z8s/r@smile.fi.intel.com>
Date:   Wed, 6 Sep 2023 19:03:17 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Mehdi Djait <mehdi.djait.k@...il.com>,
        krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
        lars@...afoo.de, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v8 6/7] iio: accel: kionix-kx022a: Add a function to
 retrieve number of bytes in buffer

On Tue, Aug 29, 2023 at 09:33:27AM +0300, Matti Vaittinen wrote:
> On 8/28/23 13:53, Andy Shevchenko wrote:
> > On Mon, Aug 28, 2023 at 09:24:25AM +0300, Matti Vaittinen wrote:
> > > On 8/27/23 21:09, Jonathan Cameron wrote:

Sorry it took a bit of time to reply on this.

...

> > > I think that people who work on a driver like this should guess what this is
> > > for.
> > 
> > _This_ is the result of what people always forgot to think about, i.e. newcomers.
> 
> Thanks Andy. This was a good heads-up for me. I do also see the need for
> fresh blood here - we aren't getting any younger.
> 
> > What _if_ the newcomer starts with this code and already being puzzled enough on
> > what the heck the function does. With all ambiguity we rise the threshold for the
> > newcomers and make the kernel project not attractive to start with
> 
> I really appreciate you making a point about attracting newcomers (and there
> is no sarcasm in this statement). I however don't think we're rising the bar
> here. If a newcomer wants to work on a device-driver, the _first_ thing to
> do is to be familiar with the device. Without prior experience of this kind
> of devices it is really a must to get the data-sheet and see how the device
> operates before jumping into reading the code. I would say that after
> reading the fifo lvl description from data-sheet this should be obvious -
> and no, I don't think we should replicate the data-sheet documentation in
> the drivers for parts that aren't very peculiar.

There are (at least?) two approaches on the contribution:
1) generic / library wise;
2) specific hardware wise.

You are talking about 2), while my remark is about both. I can imagine a newcomer
who possess a hardware that looks similar to what this driver is for. Now, they
would like to write a new driver (note, that compatibility can be checked by
reading the RTL definitions, so no need to dive into the code) and use this as
a (nice) reference. With that in mind, they can read a function named
get_fifo_bytes() with not so extensive documentation nor fully self-explanatory
name. One may mistakenly though about this as a function for something that
returns FIFO capacity, but in the reality it is current amount of valid / data
bytes in the FIFO for the ongoing communication with the device.

> But the question how to attract newcomers to kernel is very valid and I
> guess that not too many of us is thinking of it. Actually, I think we should
> ask from the newcomers we have that what has been the most repulsive part of
> the work when they have contributed.

> (besides the
> > C language which is already considered as mastodon among youngsters).
> 
> I think this is at least partially the truth. However, I think that in many
> cases one of the issues goes beyond the language - many younger generation
> people I know aren't really interested in _why_ things work, they just want
> to get things working in any way they can - and nowadays when you can find a
> tutorial for pretty much anything - one really can just look up instruction
> about how a "foobar can be made to buzz" instead of trying to figure out
> what makes a "foobar to buzz" in order to make it to buzz. So, I don't blame
> people getting used to take a different approach. (Not sure this makes sense
> - don't really know how to express my thoughts about this in a clear way -
> besides, it may not even matter).

Yeah, I share your frustration and agree that people are loosing the feel of
curiosity. Brave New World in front of us...

> Anyways, I am pretty sure that - as with any community - the way people are
> treated and how their contribution is appreciated is the key to make them
> feel good and like the work. I think that in some cases it may include
> allowing new contributors to get their code merged when it has reached "good
> enough" state - even if it was not perfect. (Sure, when things are good
> enough is subject to greater minds than me to ponder) ;)

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists