On 6/4/19 2:31 PM, Douglas Gilbert wrote:
Then there is the case of a driver maintainer
who wants to clean up code that has "rusted" over time, including
being weakened by hundreds of well-meaning but silly janitor type
patches. Should a maintainer be discouraged from doing that?
I think in this case the answer to that question is "yes, definitely".
Multiple companies, including my employer, use the SG I/O interface as
the primary interface for controlling SMR drives. Any regression in the
SG I/O code will have severe consequences for users of SMR drives. As
you know a rewrite can introduce regressions. Since the current
implementation works fine I think it is up to you to find a way to
motivate existing SG I/O users to adopt your new implementation. The
cloud companies I know employ kernel developers and test new kernel
versions before deploying these internally. How are you going to
motivate these companies to adopt your rewrite instead of combining e.g.
the Linux kernel v5.1 SG I/O implementation with the latest version of
the Linux kernel?
To date I have had no feedback about design document describing this
patchset:
http://sg.danny.cz/sg/sg_v40.html
even though I refer to sections of it in about half of the patches
in this patchset. Plus I have written extensive test code and made
it available; again no feedback on that.
It is great that you took the time to write a design document. I can't
speak for other kernel developers. But if I see a URL myself in a cover
letter of a patch series or in a commit message I ignore it. If you want
feedback on that design document please convert it into a documentation
patch and include it in this patch series.
Thanks,
Bart.
