From: Bart Van Assche <bvanassche@acm.org>
To: Hannes Reinecke <hare@suse.de>, Yanling Song <songyl@ramaxel.com>,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, yujiang@ramaxel.com
Subject: Re: [PATCH V2] scsi:spraid: initial commit of Ramaxel spraid driver
Date: Mon, 6 Dec 2021 09:00:56 -0800 [thread overview]
Message-ID: <7d6f4200-9140-5f1c-b962-8762703ccba1@acm.org> (raw)
In-Reply-To: <99fb2d55-88c0-2911-3b71-7670d386ab1c@suse.de>
On 11/29/21 5:04 AM, Hannes Reinecke wrote:
> This entire thing looks like an NVMe controller which is made to look like a SCSI controller.
> It even uses most of the NVMe structures.
> And from what I've seen there is not much SCSI specific in here; I/O and queue setup is pretty much what every NVMe controller does.
> So why not make it a true NVMe controller?
> Yes, you would need to discuss with the NVMe folks on how a RAID controller should look like in NVMe terms.
> But overall I guess the driver would be far smaller and possibly easier to maintain.
>
> So where's the benefit having it as a SCSI driver (apart from the fact that is allows you to side-step having to discuss the interface with NVMexpress.org ...)?
> Or, to put it the other way round: Is there anything SCSI specific which would prevent such an approach?
Hi Hannes,
Isn't every driver that defines a struct scsi_host_template by definition a
SCSI driver?
If there is enough code that is shared between the spraid driver and the NVMe
core one could look into creating a library with the shared code. However,
I'm not sure this is worth the effort nor that the NVMe maintainers will
agree with this.
Thanks,
Bart.
next prev parent reply other threads:[~2021-12-06 17:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-26 7:33 [PATCH V2] scsi:spraid: initial commit of Ramaxel spraid driver Yanling Song
2021-11-26 16:21 ` James Bottomley
2021-11-26 19:24 ` Randy Dunlap
[not found] ` <20211130113449.45751209@songyl>
2021-12-01 0:26 ` Yanling song
2021-11-29 13:04 ` Hannes Reinecke
[not found] ` <20211130113836.1bb8e91c@songyl>
2021-11-30 11:55 ` Hannes Reinecke
2021-12-02 13:56 ` Yanling song
2021-12-06 17:00 ` Bart Van Assche [this message]
2021-12-09 23:15 ` Bart Van Assche
2021-12-10 17:42 ` Bart Van Assche
2021-12-12 3:02 ` Yanling song
2021-12-10 21:40 ` Bart Van Assche
2021-12-12 3:04 ` Yanling song
2021-12-12 2:56 ` yanling.song
2021-12-27 7:55 ` Yanling Song
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=7d6f4200-9140-5f1c-b962-8762703ccba1@acm.org \
--to=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=songyl@ramaxel.com \
--cc=yujiang@ramaxel.com \
/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).