Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
3
-
9223372036854775807
Description
This re-adds the lustre-devel package.
Attachments
Issue Links
- is related to
-
LU-9897 Tracking of lustre library improvements.
-
- Open
-
Activity
simmonsja, FYI: https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lnet.pc and https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lustre-api-devel.pc
James, that could go under a separate ticket? My understanding is that would be something quite different - building out-of-tree kernel modules, rather than the patch which just landed, which is for userspace tools that need access to the interface/protocol structures and constants and such?
Actually one more patch. People want the ability to build against external LND drivers.
Landed for 2.14Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40728/
Subject: LU-9215 build: Re-add the lustre-devel package
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 16af4e5ed634942cf6d8a847832684c5542a956c
By popular demand I added back lustre-devel for user land handling. As for what people are requesting that is kmod-lustre-devel rpm that you want.
James Simmons (jsimmons@infradead.org) uploaded a new patch: https://review.whamcloud.com/40728
Subject: LU-9215 build: Re-add the lustre-devel package
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1d71647c5ce75d7d7dbd464e218764b7314b7811
I don't think there is any question about the kernel or Lustre APIs being kept stable,, but that doesn't prevent modules from having conditional compilation as we already do with Lustre today.
I don't object in principle to our-of-tree modules being built, but agree that "lustre-devel" is maybe not a good package name unless it also includes both the in-kernel and userspace development headers.
That is not how devel rpms work. They normally contain only static libraries and user land headers. Your ptl4lnd driver is a kernel driver so its going to always be dependent on the lustre kernel code 
Their is no guarantee that the internal kernel apis will remain stable. In fact more changes to the LNet core are in the pipe line.
spiechurski, I'm not against having a lustre-devel package per-se, but I am against including every header into that package. My preference would be to include header files into that package on an as-needed basis to build the required modules, rather than including everything. That avoids adding dependence on internal implementation details that are not really forming a stable API, and also makes it easier to see which interfaces are actually being used by external modules.
On the other hand, is there a reason that the ptl4lnd is not submitted into the master branch? That would simplify keeping it updated for newer Lustre releases, since you will have at least some of the ptl4lnd updates as part of the ongoing development activities by other parties, even if the LND is itself not always being tested for each patch. Having a small test system at Atos that is fetching any patches from Gerrit that affect LNet and running a brief test (e.g. lnet-selftest with NETTYPE=ptl4) would go a long way to ensuring that this LND does not break.
Andreas I can do that. The only reason I brought this up is that people earlier in this ticket asked for it. Also patch https://review.whamcloud.com/#/c/25997 seemed to be heading into that direction instead of handling the user land devel package handling. Cory those *.pc inspired me to develop the patch that just landed