lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1o9pyfs02.fsf@oracle.com>
Date:   Mon, 25 Sep 2017 16:22:21 -0400
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Suganath Prabu Subramani <suganath-prabu.subramani@...adcom.com>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org,
        Sathya Prakash <Sathya.Prakash@...adcom.com>,
        Kashyap Desai <kashyap.desai@...adcom.com>,
        linux-kernel@...r.kernel.org,
        Chaitra Basappa <chaitra.basappa@...adcom.com>,
        Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
        linux-nvme@...ts.infradead.org,
        Jayant Daftardar <jayant.daftardar@...adcom.com>
Subject: Re: [PATCH v4 00/14] mpt3sas driver NVMe support:


Hi Suganath,

> Also, Making all PRP buffer may or may not need FW changes (assuming
> it is possible.), we may end up into multiple FW version check.

I don't understand how submitting an I/O that is guaranteed to honor the
constraints of the target NVMe drive could possibly cause problems for
the controller firmware. Quite the contrary, it's the best case
scenario.

> Since this is main IO path and current driver is following H/W
> limitation, we should avoid any changes in this area until and unless
> change is universal acceptable in FW (for all type of work load).

This is why you need to involve the Linux community early in the design
process and not when your implementation is complete.

We could have told you right away what the correct approach would be for
your Linux driver. And that said approach works for products from other
vendors so we see no compelling reason to deviate from it.

As evidenced by Broadcom disowning the legacy mpt and megaraid drivers,
I will be stuck maintaining this mpt3sas code for a decade or more. Long
after Broadcom has ended official support and moved on to different
ASICs and programming interfaces. Consequently, I am very heavily biased
towards solutions that leverage the shared interfaces provided by the
kernel and that don't have special cases and workarounds inside the
driver.

-- 
Martin K. Petersen	Oracle Linux Engineering

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ