Re: [PATCH v8 6/7] iio: accel: kionix-kx022a: Add a function to retrieve number of bytes in buffer

From: Matti Vaittinen
Date: Thu Sep 07 2023 - 12:19:43 EST

On 9/6/23 19:03, Andy Shevchenko wrote:
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.

No problem. Autumn is approaching and darkness is falling in Finland... So, at least I am really slowing down with everything... :|

...

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.

Yes. I am talking about 2). And my stance is that device drivers belong to category 2). If one works with a device driver for some HW, then he/she needs to be willing to understand the hardware.

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.

I can't avoid having a feeling that this is a very unlikely scenario. I am afraid that by requesting this type of improvements at patch series which is at v8 and has been running for half an year (and which was of a good quality to start with, especially knowing this was the author's first driver) is going to be more repulsive to the newcomers than the potential obfuscation.

I don't try claiming that no-one could ever hit this trap (even if I don't see it likely). I still believe that if one does so, he/she will also get such a bug fixed without being totally discouraged - it's business as usual.

I hope this does not come out as rude. I do appreciate your reviews, it's comforting to know someone looks my code with sharp eyes and points out things like the dead code in BM1390 driver! I just like the words Jonathan once spilled out:

"Don't let the perfect be enemy of good" (or something along those lines).

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...

Well, who knows how things will be working out for the new generations? Maybe they won't need the kernel in the future? Yes, I am stubbornly hanging in the past practices and values. Direction things seem to head do not always appeal to me - but perhaps it's just me? Who can say my values and practices are the right ones for new generations :) My oldest son just moved to his own home and I need to accept that young do build their own lives on different values I had. And who knows, maybe the approach of just doing things without knowing what exactly happens under the hood makes this world very good for them?

But yes - I don't think it suits the kernel project at all :) This is a project of dinosaurs like us XD

(DISCLAIMER: I don't know quite all young people in the world. Frankly to tell, not even 90% XD So, I am not trying to say "all young people are like this or that". I just have a feeling that certain way of thinking is more common amongst certain generations - but maybe it's just my misjudgement. Please, don't be offended).


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) ;)


--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~