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

[Matti Vaittinen <mazziesaccount@gmail.com>]

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! ~~