lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ