Details
-
Bug
-
Resolution: Fixed
-
Major
-
Lustre 2.4.0, Lustre 2.4.1, Lustre 2.5.0, Lustre 2.4.2, Lustre 2.5.1, Lustre 2.4.3
-
3
-
13871
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.
Attachments
Issue Links
- is blocked by
-
LU-4998 lustre_idl.h compilation regression from LU-2684
-
- Resolved
-
-
LU-5000 lustre_idl.h compilation regression from ORNL-10
-
- Resolved
-
-
LU-4997 lustre_idl.h compilation regression from LU-2743
-
- Closed
-
-
LU-4999 lustre_idl.h compilation regression from LU-3569
-
- Closed
-
- is related to
-
LU-5327 powerpc64 defines __u64 differently for kernel- and user-space
-
- Resolved
-
-
LU-5065 lfs should dogfood llapi
-
- Closed
-
-
LU-6245 Untangle userland and kernel space support for libcfs
-
- Resolved
-
- is related to
-
LU-5001 Backport needed to b2_4 of "LU-1606 idl: remove LASSERT/CLASSERT from lustre_idl.h"
-
- Resolved
-
-
LU-1606 lustre_idl.h does not compile in user-space
-
- Closed
-
-
LU-6401 Untangle lustre userland and kernel headers
-
- Resolved
-
I was primary referring to 4, lu_uintXX_t. I think that takes us in the wrong direction.
I find __uXX types a little less bothersome. But if anything, it sees like we should use the uXX and sXX forms rather than the forms that are preceded with underscores when we wish to share with userspace.
Overall I am still thinking uintXX_t is probably the best way to go.