On Mon, 18 Oct 2021, Jens Axboe wrote:
Oh please, can we skip the empty words, this is tiresome and unproductive. Since you apparently have a much better grasp on this than I do, answer me this: 1) How many users of ataflop are there? 2) How big of a subset of that group are capable of figuring out where to send a bug report?
Both good questions. Here are some more. 3) How many users is sufficient to justify the cost of keeping ataflop around? 4) How long is the user count allowed to remain below that threshold, before the code is removed?
By your reasoning, any bug would go unreported for years, no matter how big the user group is. That is patently false.
No, those are your words, not mine.
It's most commonly a combination of how hard it is to hit, and how many can potentially hit it. Yes, some people will work around a bug, but others will not. Hence a subset of people that hit it will report it. Decades of bug reports have proven this to be true on my end.
I agree that a bug report count can be a proxy for a user count, but there is always a confidence level attached to such statistical reasoning, which can and should be quantified.
Nobody has reported the ataflop issue in 3 years. Either these people never upgrade (which may be true), or none of them are using ataflop. It's as simple as that.
It is when you over-simplify. The mere fact that Michael is working on this driver publicly will probably increase its user base. I think you and I both know that code with non-zero user count regularly gets removed. I think the main criterion for keeping code around has always been the expense. So I help with API modernization for the drivers I'm responsible for, to make them cheaper to keep around. Other people concerned about the cost of keeping code in the tree should look at drivers which only work on devices with vendor kernels. And they should consider the size of those drivers. When kernel.org has dropped all the code in that category, then sure, let's worry about a few tiny old legacy drivers.
