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. ... > > > 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. 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. > 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... > 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) ;) -- With Best Regards, Andy Shevchenko
