From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Sven Peter <sven@svenpeter.dev>,
linux-nvme@lists.infradead.org
Subject: Re: [asahilinux:nvme/dev 13/17] drivers/nvme/host/pci.c:2249:2-3: Unneeded semicolon
Date: Mon, 9 Aug 2021 12:02:55 +0200 [thread overview]
Message-ID: <CAK8P3a2t8qAr1q6uf-wuer6rpZnmOmZ1LytO6vOGXKT1DR2OmA@mail.gmail.com> (raw)
In-Reply-To: <YQ7GVu1TqpqbHZOb@infradead.org>
+ On Sat, Aug 7, 2021 at 7:43 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> FYI, I think the approach to mess up the nvme-pci driver in this
> branch is completely unacceptable for upstream.
>
> Please create an entirely separate driver plugging into nvme_ctrl_ops.
Hi Christoph,
I wrote the initial version of the series with the intention for testing
out how much of the code can be shared between the pci_driver
and the platform_driver version.
I tried to avoid moving around or duplicating code for this, to make
it easier to rebase until we have decided what the final code should
look like. It would be fairly easy to take the version that sven is
testing, and then remove all the PCI bits from that driver to get
to a separate nvme_ctrl_ops implementation, but that does mean
a great deal of duplication. I initially planned to send my patches
as an RFC to the list, but I never managed to get it working before
I lost access to the machine I had. Sven got it working fine with a
little rework then.
Out of the 3557 lines for the combined pci/platform driver, I ended
up with 475 lines that are specific to the PCI version, and 104
lines that are specific to the platform driver. There are probably
a few more bits that could be removed from a platform-only version,
but I still expect the majority of the code to be the same, which is why
I was hoping we could rearrange the code in a way that puts those
into a library module, either as part of the existing nvme-core.ko,
or a new nvme-mmio.ko that is used by both pci and platform
front-ends.
Simply moving the common functions into a separate file, and
exporting the symbols would work, but probably won't lead to
the best structure without some more rework.
Do you have any further suggestions? Should we just duplicate
the driver and then simplify the platform version as much as possible
as you suggested above, or try to share some of the code according
to my original plan?
Arnd
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next parent reply other threads:[~2021-08-09 10:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202108051646.vdMMUBea-lkp@intel.com>
[not found] ` <YQ7GVu1TqpqbHZOb@infradead.org>
2021-08-09 10:02 ` Arnd Bergmann [this message]
2021-08-09 14:29 ` [asahilinux:nvme/dev 13/17] drivers/nvme/host/pci.c:2249:2-3: Unneeded semicolon Christoph Hellwig
2021-08-09 15:53 ` Arnd Bergmann
2021-08-09 20:11 ` Sven Peter
2021-08-18 6:26 ` Sven Peter
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=CAK8P3a2t8qAr1q6uf-wuer6rpZnmOmZ1LytO6vOGXKT1DR2OmA@mail.gmail.com \
--to=arnd@arndb.de \
--cc=hch@infradead.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sven@svenpeter.dev \
/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).