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

Finn Thain
2021-10-19T00:14:36Z

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.