On 5/4/18 10:58 PM, Stephen Hemminger wrote:
> On Fri, 4 May 2018 16:13:07 -0600
> David Ahern <dsah...@gmail.com> wrote:
>
>> On 5/4/18 3:56 PM, Stephen Hemminger wrote:
>>> All user api headers in iproute2 should be in include/uapi
>>> so that script can be used to put correct sanitized kernel headers
>>> there. And the header files for rdma must be a complete set; if one
>>> header file includes another, all must be present.
>>>
>>> This fixes build on older distributions, and Windows Services
>>> for Linux.
>>>
>>> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
>>> ---
>>> include/uapi/rdma/ib_user_sa.h | 77 ++
>>> include/uapi/rdma/ib_user_verbs.h | 1210 +++++++++++++++++
>>> .../uapi/rdma/rdma_netlink.h | 13 +
>>> .../uapi/rdma/rdma_user_cm.h | 6 +-
>>> 4 files changed, 1303 insertions(+), 3 deletions(-)
>>> create mode 100644 include/uapi/rdma/ib_user_sa.h
>>> create mode 100644 include/uapi/rdma/ib_user_verbs.h
>>> rename {rdma/include => include}/uapi/rdma/rdma_netlink.h (95%)
>>> rename {rdma/include => include}/uapi/rdma/rdma_user_cm.h (98%)
>>>
>>
>> Stephen:
>>
>> Per a recent discussion the RDMA folks need to take ownership of the
>> uapi files. RDMA features do not hit Dave's net-next tree so the rdma
>> code can never hit iproute2-next during a dev cycle.
>
> I want all uapi headers in include/uapi because it avoids possible overlap
> problems,
> During the linux-net/linus release cycle they should match what is Linus's
> tree.
>
> During the net-next they can come from two sources.
>
That creates extra work for me for no reason.
You state above "user api headers in iproute2 should be in include/uapi
so that script can be used to put correct sanitized kernel headers there."
With RDMA's development cycle that will *never* happen. With the
exception of RDMA, all iproute2 features go through net-next and it is
the right tree to pull updates from. Every time I sync from net-next the
header files for rdma will have to be ignored, so they will never be
updated through this mechanism which means the stated goal is not
achievable.
As for linux-next, I will not sync header files to a tree that
disappears; it breaks all traceability. Further, it seems to me that it
does not really solve the problem. I forget the steps now but RDMA
features have to hit some development tree before going to Linus, so
there will be a delay with the headers.
Back in March we discussed options. iproute2 is nothing more than a
delivery vehicle for rdmatool. Since it breaks everything else about the
iproute2 and net-next association, the simplest option for everyone is
for the rdma group to control syncing their own headers and putting them
under rdma directory.
