On 3/20/18 11:21 AM, Doug Ledford wrote: > On 3/16/2018 12:18 PM, David Ahern wrote: >> On 3/13/18 1:58 PM, Doug Ledford wrote: >>> On Tue, 2018-03-13 at 13:45 -0700, David Ahern wrote: >>>> On 3/13/18 1:32 AM, Leon Romanovsky wrote: >>>>> On Mon, Mar 12, 2018 at 10:53:03AM -0700, David Ahern wrote: >>>>>> On 3/12/18 8:16 AM, Steve Wise wrote: >>>>>>> Hey all, >>>>>>> >>>>>>> The kernel side of this series has been merged for rdma-next [1]. Let >>>>>>> me >>>>>>> know if this iproute2 series can be merged, of if it needs more changes. >>>>>>> >>>>>> >>>>>> The problem is that iproute2 headers are synced to kernel headers from >>>>>> DaveM's tree (net-next mainly). I take it this series will not appear in >>>>>> Dave's tree until after a merge through Linus' tree. Correct? >>>>> >>>>> David, >>>>> >>>>> Technically, you are right, and we would like to ask you for an extra >>>>> tweak >>>>> to the flow for the RDMAtool, because current scheme causes delays at >>>>> least >>>>> cycle. >>>>> >>>>> Every RDMAtool's patchset which requires changes to headers is always >>>>> includes header patch, can you please accept those series and once you >>>>> are bringing new net-next headers from Linus, simply overwrite all our >>>>> headers? >>>> >>>> I did not follow the discussion back when this decision was made, so how >>>> did rdma tool end up in iproute2? >>> >>> It is modeled after the ip command, and for better or worse, the >>> iproute2 package has become the standard drop box for low level kernel >>> network configuring tools. The RDMA subsystem may not be IP networking, >>> but it is still networking, so it seemed an appropriate fit. >> >> why doesn't the rdma tree go through Dave then? >> > > Because it doesn't use the core network stack hardly at all. It creates > netdevs when it needs to bridge the two stacks, but otherwise the RDMA > subsystem core is apart and unique from the network stack Dave manages. > When I said it was networking, I meant it literally. The RDMA fabrics > are networks. It wasn't meant to imply that they shared anything > substantial in common with the typical Ethernet/IP networking that is > the core of what Dave manages. >
I think the simplest approach is to move the uapi header under the rdma directory and you folks take ownership of that header.
