[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

[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.

[Christopher Morrone (Inactive)]

Ah, great! Good riddance.

The manual should have a note to users about lustre_idl.h's disappearance.

[Sarah Liu]

Hi Christopher,

I didn't test lustre_idl.h because it has been removed
http://review.whamcloud.com/#/c/10215

[root@client-18 lustre]# ls
liblustreapi.h ll_fiemap.h lustreapi.h lustre_user.h
[root@client-18 lustre]# pwd
/usr/include/lustre

[Christopher Morrone (Inactive)]

Wait, wait, wait. Why did you test lustreapi.h, lustre_user.h, and ll_fiemap.h when this ticket is very explicitly about lustre_idl.h?

[Peter Jones]

Thanks Sarah. This ticket will remain open as there are other subtasks still open but it sounds like the most critical tasks that were considered in scope for 2.6 are now complete so I am dropping that FixVersion and lowering the priority

[Sarah Liu]

I tried against the latest master build #2072, no warnings.
It seems sanity.sh 400a and 400b have done the tests already

[root@client-18 ~]# cat 5011_example.c 
#include <lustre/lustreapi.h>
#include <lustre/lustre_user.h>
#include <lustre/ll_fiemap.h>

main() {}
[root@client-18 ~]# gcc 5011_example.c -llustreapi
[root@client-18 ~]#

[John Hammond]

> Looking at a FC13 test system I have, <linux/types.h> is part of kernel-headers*.rpm, which is required by glibc-headers, which is required by glibc-headers, which is required by glibc-devel, which is required by gcc, so it does indeed seem that <linux/types.h> is going to be installed on any system that is compiling something on Linux.

This is a tenuous dependency. None of the headers in /usr/include/, /usr/include/bits/ or /usr/include/sys/ include linux/types.h or use any of the __uXX typedefs. sys/kd.h even defines _LINUX_TYPES_H so that including linux/kd.h will not pull in linux/types.h.

> I think it makes sense to go back to http://review.whamcloud.com/#/c/10258/1/libcfs/include/libcfs/posix/posix-types.h which includes <linux/types.h> on any Linux system.

I agree that in the short term this is the best fix.

[Andreas Dilger]

Looking at a FC13 test system I have, <linux/types.h> is part of kernel-headers*.rpm, which is required by glibc-headers, which is required by glibc-headers, which is required by glibc-devel, which is required by gcc, so it does indeed seem that <linux/types.h> is going to be installed on any system that is compiling something on Linux.

I think it makes sense to go back to http://review.whamcloud.com/#/c/10258/1/libcfs/include/libcfs/posix/posix-types.h which includes <linux/types.h> on any Linux system.

[Christopher Morrone (Inactive)]

Seems like an odd choice. But Linux is just odd that way sometimes, I guess.

I guess I'm fine with use of the __u* as long as it is for things that interface directly with the kernel.

[Andreas Dilger]

Actually, the reverse is true - the __u* versions are for interface usage, and u* is for kernel internal use. Please don't go the opposite way from the kernel.