[LU-5011] lustre_idl.h again does not compile in user space

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.10.0
• Affects Version/s: Lustre 2.4.0, Lustre 2.4.1, Lustre 2.5.0, Lustre 2.4.2, Lustre 2.5.1, Lustre 2.4.3
• Labels: llnl
• Severity: 3
• Assignee: John Hammond
• Reporter: Christopher Morrone (Inactive)

Description

New ticket for the the recurring problem of lustre_idl.h not compiling in user-space. Conversation began in LU-1606, but we want to have a separate ticket for Lustre 2.6.0.

Issue Links

• is blocked by: LU-4998 lustre_idl.h compilation regression from LU-2684
• is blocked by: LU-5000 lustre_idl.h compilation regression from ORNL-10
• is blocked by: LU-4997 lustre_idl.h compilation regression from LU-2743
• is blocked by: LU-4999 lustre_idl.h compilation regression from LU-3569
• is related to: LU-5327 powerpc64 defines __u64 differently for kernel- and user-space
• is related to: LU-5065 lfs should dogfood llapi
• is related to: LU-6245 Untangle userland and kernel space support for libcfs
• is related to: LU-5001 Backport needed to b2_4 of "LU-1606 idl: remove LASSERT/CLASSERT from lustre_idl.h"
• is related to: LU-1606 lustre_idl.h does not compile in user-space
• is related to: LU-6401 Untangle lustre userland and kernel headers

Comments

[James A Simmons]

This ticket can be closed since we have test sanity 400b to make sure this doesn't happen again.

[Cory Spitz]

Thanks, that makes sense. Since there is activity here, maybe someone can add that definition to the file in the next commit.

[Robert Read]

Since Lustre is based on an RCP interface, most likely it's a reference to Interface Definition Language, such as the kind used with rpcgen to use SUNRPC and similar RPC implementations.

[Cory Spitz]

What does IDL even stand for?

[James A Simmons]

With the work of LU-6401 I started to look closely at lustre_idl.h and I noticed its not really needed to user land except for wiretest and the wirechecker hack. It might be possible to make lustre_idl.h a kernel space only header.

[James A Simmons]

That is excellent that some functions for liblustreapi has to be redone. We can move that code to liblustre_util.c and make it LGPL
Please do send you WIP patch. I will gladly move it forward. I myself started to unwind the libcfs.h mess for the user land tools and utilities.

[Andreas Dilger]

When I was looking through this before the developer workshop I also saw this issue with kernel headers included into userspace. However, most of those headers are not actually needed for liblustreapi to work. I should send you my WIP patch for cleaning up some of those dependencies. In some cases it means reimplementing llapi functions to use different APIs (e.g. getting the Lustre version), but that's OK and maybe even desirable. In other cases, we just need to disentangle the headers, and only include the needed headers into userspace, rather than generic ones like "libcfs.h".

[James A Simmons]

I was surprised that liblustreapi still required lustre_idl.h. As I cleanup the libcfs header dependencies I noticed that the lustre headers relating to the utils is just a mess. Many lustre kernel headers are being pulled into the utils library. There is no clear separation of the layers and headers are placed either in lustre/include or lustre/include/lustre for the utils. This will need to be cleaned up.

[John Hammond]

> While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build.

That's intentional. lustre_idl.h will not be packaged. llapi is the public interface.

[James A Simmons]

While doing the libcfs cleanup I discovered that while lustre_idl.h is not exported for user land in the rpms liblustreapi still depends on this header to build.