On 16/06/2020 16:09, Bart Van Assche wrote:
> On 2020-06-16 02:42, Finn Thain wrote:
>> Martin said, "I'd appreciate a patch to remove it"
>>
>> And Bart said, "do you want to keep this driver in the kernel tree?"
>>
>> AFAICT both comments are quite ambiguous. I don't see an actionable
>> request, just an expression of interest from people doing their jobs.
>>
>> Note well: there is no pay check associated with having a MAINTAINERS file
>> entry.
>
> Hi Finn,
>
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver. So why to keep it in the kernel tree?
> Restoring a kernel driver can be easy - the first step is a "git revert".
Why not move the driver to drivers/staging for 2 or 3 kernel releases and if
noone steps up, delete it?
Just my 2 Cents,
Johannes
On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
> On 16/06/2020 16:09, Bart Van Assche wrote:
> > On 2020-06-16 02:42, Finn Thain wrote:
> > > Martin said, "I'd appreciate a patch to remove it"
> > >
> > > And Bart said, "do you want to keep this driver in the kernel
> > > tree?"
> > >
> > > AFAICT both comments are quite ambiguous. I don't see an
> > > actionable request, just an expression of interest from people
> > > doing their jobs.
> > >
> > > Note well: there is no pay check associated with having a
> > > MAINTAINERS file
> > > entry.
> >
> > Hi Finn,
> >
> > As far as I know the sbp driver only has had one user ever and that
> > user is no longer user the sbp driver. So why to keep it in the
> > kernel tree? Restoring a kernel driver can be easy - the first step
> > is a "git revert".
>
> Why not move the driver to drivers/staging for 2 or 3 kernel releases
> and if noone steps up, delete it?
Because that's pretty much the worst of all worlds: If the driver is
simply going orphaned it can stay where it is to avoid confusion. If
it's being removed, it's better to remove it from where it is because
that makes the patch to restore it easy to find.
Chris, the thing is this: if this driver has just one user on a stable
distro who complains about its removal six months to two years from
now, Linus will descend on us from a great height (which won't matter
to you, since you'll be long gone). This makes everyone very wary of
outright removal. If you're really, really sure it has no users, it
can be deleted, but if there's the slightest chance it has just one, it
should get orphaned.
James
On 16/06/2020 16:34, James Bottomley wrote:
> On Tue, 2020-06-16 at 14:13 +0000, Johannes Thumshirn wrote:
>> On 16/06/2020 16:09, Bart Van Assche wrote:
>>> On 2020-06-16 02:42, Finn Thain wrote:
>>>> Martin said, "I'd appreciate a patch to remove it"
>>>>
>>>> And Bart said, "do you want to keep this driver in the kernel
>>>> tree?"
>>>>
>>>> AFAICT both comments are quite ambiguous. I don't see an
>>>> actionable request, just an expression of interest from people
>>>> doing their jobs.
>>>>
>>>> Note well: there is no pay check associated with having a
>>>> MAINTAINERS file
>>>> entry.
>>>
>>> Hi Finn,
>>>
>>> As far as I know the sbp driver only has had one user ever and that
>>> user is no longer user the sbp driver. So why to keep it in the
>>> kernel tree? Restoring a kernel driver can be easy - the first step
>>> is a "git revert".
>>
>> Why not move the driver to drivers/staging for 2 or 3 kernel releases
>> and if noone steps up, delete it?
>
> Because that's pretty much the worst of all worlds: If the driver is
> simply going orphaned it can stay where it is to avoid confusion. If
> it's being removed, it's better to remove it from where it is because
> that makes the patch to restore it easy to find.
>
> Chris, the thing is this: if this driver has just one user on a stable
> distro who complains about its removal six months to two years from
> now, Linus will descend on us from a great height (which won't matter
> to you, since you'll be long gone). This makes everyone very wary of
> outright removal. If you're really, really sure it has no users, it
> can be deleted, but if there's the slightest chance it has just one, it
> should get orphaned.
My patch to delete the driver was based on Martin's original request:
https://lore.kernel.org/lkml/[email protected]/
I don't especially want it to be gone, nor can I be sure there are no
users of what is as far as I can tell a working piece of code. I can
tell you that I never hear about it (other than the odd patch), whereas
I do get emails out of the blue for some of my other (much smaller)
stuff which clearly has users. I'd be just as happy for this to be
orphaned or for nothing to happen to it.
Honestly, I am totally ambivalent as to what happens to this code.
Martin, however, clearly cares enough to have asked me to supply a patch
to remove it.
Cheers,
Chris
--
Chris Boot
[email protected]
Chris,
> I don't especially want it to be gone, nor can I be sure there are no
> users of what is as far as I can tell a working piece of code. I can
> tell you that I never hear about it (other than the odd patch),
> whereas I do get emails out of the blue for some of my other (much
> smaller) stuff which clearly has users. I'd be just as happy for this
> to be orphaned or for nothing to happen to it.
>
> Honestly, I am totally ambivalent as to what happens to this code.
> Martin, however, clearly cares enough to have asked me to supply a
> patch to remove it.
I love it when people take ownership of old drivers. I think it's
wonderful that Finn and others are on the ball when it comes to the 5380
family. I don't care how old things are as long as they are being
actively used.
I am also very happy to keep things in the tree as long as there is a
healthy community around them. However, keeping code around is not
free. Core interfaces change frequently. Nobody enjoys having to tweak
host templates for 50 devices they have never even heard about. Also, we
now live in a reality where there is a constant barrage of build bots
and code analyzers sending mail. So the effective cost of keeping code
around in the tree is going up. I get a substantial amount of code
analysis mail about drivers nobody have touched in a decade or more.
Consequently, I am much more inclined to remove drivers than I have been
in the past. But I am also very happy to bring them back if somebody
uses them or - even better - are willing to step up and maintain them.
I don't particularly like the notion of a driver being orphaned because
all that really means is that the driver transitions from being (at
least partially) somebody else's problem to being mine and mine alone.
--
Martin K. Petersen Oracle Linux Engineering
On Tue, 16 Jun 2020, Martin K. Petersen wrote:
>
> However, keeping code around is not free.
Right. And removing code isn't free either, if it forces people to find
workarounds.
> Core interfaces change frequently. Nobody enjoys having to tweak host
> templates for 50 devices they have never even heard about.
And yet some people seem to enjoy writing patches that are as trivial as
they are invasive...
You seem to be making an argument for more automation here, not an
argument for less code. Or is there some upper bound to the size of the
kernel, that might be lifted by adding maintainers? (Can you deliver a
better product by adding more developers to your project?)
> Also, we now live in a reality where there is a constant barrage of
> build bots and code analyzers sending mail. So the effective cost of
> keeping code around in the tree is going up.
But if maintenance cost rises due to good analysis, the value of the code
should rise too. So what's the problem? It seems to me that the real
problem is too many analyses that generate pedantic noise and no tangible
improvement in code quality or value.
> I get a substantial amount of code analysis mail about drivers nobody
> have touched in a decade or more.
>
When stable, mature code fails analysis, the analysis is also questionable
(in the absence of real examples).
> Consequently, I am much more inclined to remove drivers than I have been
> in the past. But I am also very happy to bring them back if somebody
> uses them or - even better - are willing to step up and maintain them.
>
You seem to be saying that 1) a driver should be removed when it no longer
meets the present threshold for code quality and 2) that a low quality
driver is eligible for re-addition because someone wants to use it.
I don't think you can have it both ways.
> I don't particularly like the notion of a driver being orphaned because
> all that really means is that the driver transitions from being (at
> least partially) somebody else's problem to being mine and mine alone.
>
Yes it's your problem but only on a best-effort basis.
Many issues detected by automatic analyzers can be fixed with automatic
code transformation tools. This kind of solution works tree-wide, so even
if some defect in your driver is "yours and yours alone", the solution
will probably come from others.
This email, like yours, is just hand-waving. So feel free to ignore it or
(preferably) provide evidence of real defects.