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