Re: [PATCH RFC] block - ataflop.c: fix breakage introduced at blk-mq refactoring

[Finn Thain <fthain@linux-m68k.org>]

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.