https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-9215 Lustre <p>This re-adds the lustre-devel package.</p> LU-9215

build: Re-add the lustre-devel package.

Bug Major Closed Fixed James A Simmons parinay v kondekar Wed, 15 Mar 2017 12:47:06 +0000 Fri, 18 Dec 2020 20:22:29 +0000 Fri, 18 Dec 2020 20:22:29 +0000 Lustre 2.14.0 0 11 <p>Parinay Kondekar (parinay.kondekar@seagate.com) uploaded a new patch: <a href="https://review.whamcloud.com/25997" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/25997</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9215" title="build: Re-add the lustre-devel package." class="issue-link" data-issue-key="LU-9215"><del>LU-9215</del></a> build: Re-add the lustre-devel package.<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 9022560c5978768aada71bec251db751837f32c3</p> <p>Hi <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=parinay" class="user-hover" rel="parinay">parinay</a>,</p> <p>Could you elaborate the reason we want devel packages? is there anything you are doing that can't be done with existing packages?</p> <p>Building other tools that want to use Lustre also needs this, such as Robinhood.</p> <p>Brian, I agree that based on the name "<tt>lustre-devel</tt>" one would assume this would be used by externally-built packages, but if you look at the patch it includes every header from the Lustre source tree (including kernel headers). I would instead expect that <tt>lustre-devel</tt> would include the <tt>lustre/include/lustre</tt> directory headers, and the <tt>liblustreapi.a</tt> library (the <tt>liblustreapi.so</tt> library should always be installed).</p> <p>Can we reconsider this ticket ?</p> <p>We have a use-case where such a package would be useful: we build an external LND, which needs to be rebuilt with each new lustre release. Having the headers (mainly lustre/include libcfs/include  and lnet/include), the config.h and the Module.symvers file for a given build in a package would help streamlining the build process.</p> <p>Would a revised patch that provides such a package with these files (filtering out the kernel headers) be acceptable ?</p> <p>About the liblustreapi.a, as it is already part of the main lustre rpm, I guess it does not really need to be provided by the -devel package.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=spiechurski" class="user-hover" rel="spiechurski">spiechurski</a>, I'm not against having a lustre-devel package per-se, but I <b>am</b> 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.</p> <p>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. <tt>lnet-selftest</tt> with <tt>NETTYPE=ptl4</tt>) would go a long way to ensuring that this LND does not break.</p> <p>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 <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> 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. </p> <p>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. </p> <p>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. </p> <p>James Simmons (jsimmons@infradead.org) uploaded a new patch: <a href="https://review.whamcloud.com/40728" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/40728</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9215" title="build: Re-add the lustre-devel package." class="issue-link" data-issue-key="LU-9215"><del>LU-9215</del></a> build: Re-add the lustre-devel package<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1d71647c5ce75d7d7dbd464e218764b7314b7811</p> <p>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. </p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/40728/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/40728/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9215" title="build: Re-add the lustre-devel package." class="issue-link" data-issue-key="LU-9215"><del>LU-9215</del></a> build: Re-add the lustre-devel package<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 16af4e5ed634942cf6d8a847832684c5542a956c</p> <p>Aa true man of the people <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> Landed for 2.14</p> <p>Actually one more patch. People want the ability to build against external LND drivers.</p> <p>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?</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=simmonsja" class="user-hover" rel="simmonsja">simmonsja</a>, FYI: <a href="https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lnet.pc" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lnet.pc</a> and <a href="https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lustre-api-devel.pc" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lustre-api-devel.pc</a></p> <p>Andreas I can do that. The only reason I brought this up is that people earlier in this ticket asked for it. Also patch <a href="https://review.whamcloud.com/#/c/25997/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/25997</a> 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 <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> Related LU-9897 Development Rank 1|hzz6yf: Rank (Obsolete) 9223372036854775807 Severity