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-next>] [day] [month] [year] [list]
Date:   Wed, 14 Mar 2018 10:31:24 -0500
From:   "Steve Wise" <swise@...ngridcomputing.com>
To:     "David Miller" <davem@...emloft.net>
Cc:     "'Raju Rangoju'" <rajur@...lsio.com>, <dledford@...hat.com>,
        <linux-rdma@...r.kernel.org>, "'Jason Gunthorpe'" <jgg@...pe.ca>,
        "netdev" <netdev@...r.kernel.org>,
        "Potnuri Bharat Teja" <bharat@...lsio.com>,
        "Ganesh Goudar" <ganeshgr@...lsio.com>,
        "Rahul Lakkireddy" <rahul.lakkireddy@...lsio.com>
Subject: interdependencies with cxgb4 and iw_cxgb4

Hey Dave,

We've been discussing dependency issues between cxgb4 and the upper layer
drivers including iw_cxgb4 on linux-rdma [1], and I want to broaden this
discussion to include netdev and you, since this involves both linux-rdma
and netdev.   (note the SRQ patch submission that triggered this discussion
was sent to linux-rdma, but it should have also included netdev.  This was
an oversight and will be corrected on the next submission depending on how
chelsio decides to proceed)

In a nutshell, Chelsio has a few patch series to submit that require
enabling some feature in cxgb4 that is then used by iw_cxgb4. SRQ support is
one such series.   The series as a whole spans both netdev and linux-rdma
maintainers.  Because of the compile dependency between iw_cxgb4 and cxgb4
introduced by this series,  the cxgb4 parts and iw_cxgb4 parts cannot be
split across maintainers.  Further, if one maintainer merges the entire
series, then there are issues if commits are submitted to the other
maintainer that conflict.

This issue has also been dealt-with for Mellanox drivers, I believe.  I take
it the solution for them was a k.o. signed repo, that they maintain, where
both linux-rdma and netdev take PRs from for commits that are needed in both
repos.   Then these are reconciled when both repos are merged into Linus'
repo. (I hope my understanding of this is correct)

For Chelsio, this is perhaps a possibility, but I'm wondering if there is a
simpler solution?  A few other option we've been discussing include:

1) submit the cxgb4-only changes to netdev in release cycle X, and then only
submit the iw_cxgb4 (or other upper drivers) changes that use them in
release cycle X+1.  The pro of this is simplicity.  The con is timeliness -
it takes 2 release cycles to get the feature upstream.

2) run the entire series through one maintainer's repo (with all
maintainers' ACK on the content and plan, of course), and ensuring no
conflicting commits are submitted for the rest of that release cycle.  I'm
not really sure that this is feasible given anyone could create commits for
upstream drivers.  So how could Chelsio really control this?

Do you have any suggestions on how we should proceed?  

[1] https://www.spinics.net/lists/linux-rdma/msg61856.html

Thanks,

Steve.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ