[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ca3b60f-e59f-b578-7c22-48487663cfa7@gmail.com>
Date: Tue, 29 Aug 2023 09:33:27 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.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 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:
>
> ...
>
>> 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.
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).
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) ;)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
Powered by blists - more mailing lists