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
-
No please don't make my eyes bleed with lu_* cfs_* types. Chris is right in that the kernel types were developed before the C99 spec. It not true that C99 types are discouraged. In fact I quote from Documentation/CodingStyle
----------------------------------------------------------------------------------------------------------------------------
(d) New types which are identical to standard C99 types, in certain
exceptional circumstances.
Although it would only take a short amount of time for the eyes and
brain to become accustomed to the standard types like 'uint32_t',
some people object to their use anyway.
Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
signed equivalents which are identical to standard types are
permitted – although they are not mandatory in new code of your
own.
When editing existing code which already uses one or the other set
of types, you should conform to the existing choices in that code.
------------------------------------------------------------------------------------------------------------------
Any non Lustre code I submit to the kernel always uses the C99 types. As for C99 types being broken that I really doubt. Their are millions of applications that depend on glibc getting it right. The last point to make is
we don't need to use linux types for kernel to userland interfaces as well. It it perfectly sane to use C99 types.
In fact to see a beautiful example of this take a look at
linux-source-tree/include/uapi/linux/fuse.h
Not a single __uXX crap thing there. Then take a look fuse_do_ioctl in linux-source-tree/fs/fuse/file.c. Again no __uXX crap. Lastly any code pushed upstream with special types will be immediately rejected.
Usually I'm pretty non bias on most things but this is not one of them.