From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: bvanassche@acm.org,
Linus Torvalds <torvalds@linux-foundation.org>,
ooo@electrozaur.com, Nathan Chancellor <natechancellor@gmail.com>,
"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
hch@infradead.org
Subject: Re: [PATCH] libosd: Remove ignored __weak attribute
Date: Fri, 26 Oct 2018 23:35:52 -0400 [thread overview]
Message-ID: <20181027033552.GA29237@thunk.org> (raw)
In-Reply-To: <CAKwvOdmUhtK10cbYFoEJJp4O8LA_F-+f68A_NcL_fm_FH6QodA@mail.gmail.com>
On Fri, Oct 26, 2018 at 03:07:39PM -0700, Nick Desaulniers wrote:
> > That's not completely correct. The standard approach to check whether or not
> > a driver is still being used is to check its git history. If the number of
> > contributors is low and it was several years ago that a new feature was added
> > or a bug has been fixed it is likely that nobody is using that driver anymore.
>
> I don't disagree with you, I just don't see how what you state can be
> reconciled with Linus' response in
> https://lkml.org/lkml/2018/10/27/44. Those two viewpoints seem
> incompatible to me, but maybe there's a nuance I'm missing?
So a couple of observations. Obviously, drivers, file systems and
architectures *have* been removed. It can be done; sometimes if it
can be demonstrate that it can't possibly work (for example, due to
bitrot, the kernel would immediately crashed if anyone tried to use
the code in question :-).
In other cases, drivers has been removed through the staging
subsystem, sometimes by adding a "depends on BROKEN" in the Kconfig
file, and seeing if anyone complains --- since removing a "depends on
BROKEN" line in Kconfig is even easier than doing reverting a git
commit (especially if the user downloaded a tarball instead of doing a
git clone).
If you've done your due diligence then the chances that you have to
revert a change which disables and later removes the dead code can be
pushed close to zero. The question is whether it's worth the effort.
> Nathan and I are just pointing out a small fix to eliminate a small
> warning, deleting all this code does kind of feels like "throwing out
> the baby with the bath water." A nuclear option for what would be a
> small change otherwise. Maybe it's good to discuss the EOL for
> exofs/osd, but can we please decouple that conversation from the small
> change Nathan and I are proposing?
The second observation I'll make is that if someone is proposing a
cleanup patch, it's unfair to dump on the person proposing the cleanup
patch the (non-trivial) effort to drop a driver/file system/subsystem.
If the maintainer wants to drop a driver/file system, that should be
the maintainer's responsibiltiy; not someone proposing a
cleanup/maintenance patch.
- Ted
next prev parent reply other threads:[~2018-10-27 3:35 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-30 20:54 [PATCH] libosd: Remove ignored __weak attribute Nathan Chancellor
2018-10-01 22:47 ` Nick Desaulniers
2018-10-02 1:16 ` Bart Van Assche
2018-10-02 6:55 ` Nathan Chancellor
2018-10-02 14:56 ` Christoph Hellwig
2018-10-02 16:59 ` Boaz Harrosh
2018-10-02 17:24 ` Nick Desaulniers
2018-10-02 17:57 ` Bart Van Assche
2018-10-02 17:57 ` Bart Van Assche
2018-10-02 22:33 ` Nick Desaulniers
2018-10-02 22:33 ` Nick Desaulniers
2018-10-02 23:06 ` Bart Van Assche
2018-10-25 21:31 ` Nathan Chancellor
2018-10-25 22:02 ` Nick Desaulniers
2018-10-25 22:55 ` Nathan Chancellor
2018-10-26 17:54 ` Nick Desaulniers
2018-10-26 17:54 ` Nick Desaulniers
2018-10-26 18:01 ` Bart Van Assche
2018-10-26 18:05 ` Nathan Chancellor
2018-10-26 18:31 ` Nick Desaulniers
2018-10-26 19:22 ` Linus Torvalds
2018-10-26 20:05 ` Nick Desaulniers
2018-10-26 20:42 ` Linus Torvalds
2018-10-26 21:02 ` Nick Desaulniers
2018-10-26 21:00 ` Nick Desaulniers
2018-10-26 21:00 ` Nick Desaulniers
2018-10-26 21:30 ` Bart Van Assche
2018-10-26 21:36 ` Nick Desaulniers
2018-10-26 21:59 ` Bart Van Assche
2018-10-26 22:07 ` Nick Desaulniers
2018-10-26 22:24 ` Bart Van Assche
2018-10-27 13:28 ` Martin K. Petersen
2018-10-28 15:44 ` Christoph Hellwig
2018-11-01 1:05 ` Boaz Harrosh
2018-10-27 3:35 ` Theodore Y. Ts'o [this message]
2018-10-27 6:15 ` Bart Van Assche
2018-10-27 6:25 ` Nathan Chancellor
2018-11-01 1:15 ` Boaz Harrosh
2018-11-01 1:39 ` Boaz Harrosh
2018-11-01 1:44 ` Nathan Chancellor
2019-01-26 6:47 ` [PATCH RESEND] " Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181027033552.GA29237@thunk.org \
--to=tytso@mit.edu \
--cc=bvanassche@acm.org \
--cc=hch@infradead.org \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=ooo@electrozaur.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.