On Thu, Sep 07, 2023 at 09:33:47AM +0300, Matti Vaittinen wrote: > 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: ... > > > > > 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 agree and this is a side talk to the topic. > 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). True. > > > 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". Operating in terms of universal quantifier is always wrong (pun intended). > 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) ;) -- With Best Regards, Andy Shevchenko
