From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net] ftgmac100: Mostly rewrite the driver
Date: Wed, 29 Mar 2017 16:18:17 +1100 [thread overview]
Message-ID: <1490764697.3177.170.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170328.221027.1436005565229924031.davem@davemloft.net>
On Tue, 2017-03-28 at 22:10 -0700, David Miller wrote:
> Do you prefer that I submit it as a new driver for that IP block
> > instead and take out the old one later ?
>
> You've decided to do this work in a way that makes it nearly
> impossible to audit the individual changes for regressions and
> whatnot.
>
> That puts a much larger burdon upon us, and introduces much greater
> potential risk.
Well, i started the "right way" ... it just got out of hand as I
realized that I had to cut deeper than I expected I would.
I may not have been very clear but the regressions etc... aren't a huge
issue at this point. The reason is that before we started putting the
aspeed SoC support upstream, there was no in-tree user of that driver,
it had been bitrotting for years. We are pretty much (OpenBMC project)
the only user at this point.
>From the testing we've done, the "new" driver is already more solid
than the previous one ever was. So we're happy to take the chance here
and submit any subsequent fix if we hit issues during testing.
> Even a "complete driver rewrite" can and very often is done in a way
> which is evolutionary rather than revolutionary. You made a
> conscious decision to just work on this internally and in such a way
> that one big huge change is the result.
Not really. I started with incremental changes. Then it got out of
control... I pretty much had to completely redo the tx and rx path,
then link monitoring, then the chip config etc...
> So, I'm sorry to say, your arguments about readability,
> realisticness,
> etc. I do not buy at all. You definitely could have done this work
> in a way which was more reviewable, and safer, but you choose not to.
>
> Now, what is going to happen, is that we'll have no choice but to
> simply accept what you've done and try and review this monster.
I'm sorry for that, but that's why I suggest treating it as a whole new
driver instead.
Viewed this way it becomes a rather simple ethernet driver.
If that's too hard, I can try to go back and re-construct the work as a
series of patches on the old driver, pulling appart the tx path
separately from the rx path, etc... but that will take quite a bit of
time.
Otherwise, if that can help, I'll submit it as a separate file
ftgmac100_new.c/.h in the email to make the review work easier, and
later a patch to take out the old one.
Cheers,
Ben.
next prev parent reply other threads:[~2017-03-29 5:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 4:40 [PATCH net] ftgmac100: Mostly rewrite the driver Benjamin Herrenschmidt
2017-03-29 4:57 ` David Miller
2017-03-29 5:03 ` Benjamin Herrenschmidt
2017-03-29 5:10 ` David Miller
2017-03-29 5:18 ` Benjamin Herrenschmidt [this message]
2017-03-29 18:08 ` Florian Fainelli
2017-03-29 21:08 ` Benjamin Herrenschmidt
2017-03-30 0:46 ` Benjamin Herrenschmidt
2017-03-30 3:15 ` David Miller
2017-03-31 9:59 ` Benjamin Herrenschmidt
2017-03-31 13:52 ` Andrew Lunn
2017-03-31 21:14 ` Benjamin Herrenschmidt
2017-03-31 21:56 ` Andrew Lunn
2017-03-31 16:56 ` David Miller
2017-03-29 17:42 ` kbuild test robot
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=1490764697.3177.170.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).