我正在开发一个设备驱动程序模块和相关的用户库来处理ioctl（）调用。 图书馆采取相关的信息，并将其放入一个结构，它被传递到驱动程序模块，并在那里解压缩，然后处理（我省略了很多步骤，但这是总体思路）。
一些通过ioctl（）传递给结构的数据是uint32_ttypes。 我发现这个types是在stdint.h和linux / types.h中定义的。 到目前为止，我一直在使用linux / types.h来定义这个值，包括在用户库中。 但是我知道在用户空间中使用linux / *。h库是一种糟糕的forms，所以如果我删除这些并使用stdint.h，那么当我的驱动程序模块包含struct定义时，必须包含stdint.h也。
在我看来，linux / types.h的目的是定义内核文件中的types，所以我不确定这是否意味着使用stdint.h是不好的主意。 我还发现，当我尝试在我的驱动程序模块中使用stdint.h时，即使我用stdint.hreplace了所有的linux / types.h实例，我也得到了关于重定义的编译错误，这些错误不会消失。包括订单的顶部）。
洙….
谢谢。
- 使用linux / *。h包含用户空间代码是不是一个好主意？
是的，通常。 典型的情况是你应该使用C库头文件（在本例中是stdint.h和friends），并且通过这些用户空间类型与C库进行交互，并让库通过内核和内核进行通信类型。
尽管如此，你并不是一个典型的情况。 就你而言，你正在编写驱动程序库 。 所以你应该使用stdint.h向用户空间展示一个接口，但是当你连接到你的内核驱动时，使用linux/*.h stdint.h头文件。
所以答案是否定的，就你而言。
- 在内核空间代码中使用stdint.h是一个坏主意吗？
绝对是的。
另见： http : //lwn.net/Articles/113349/
Linux内核中的固定长度整数
Linux内核已经有固定长度的整数可能会让你感兴趣。 在include/asm-generic/int-ll64.h ：
typedef signed char s8; typedef unsigned char u8; typedef signed short s16; typedef unsigned short u16; typedef signed int s32; typedef unsigned int u32; typedef signed long long s64; typedef unsigned long long u64;
LDD3也有关于数据大小的章节： https ：//static.lwn.net/images/pdf/LDD3/ch11.pdf
LDD3在那里提到，最好的printk策略是通过正确的签名来转换为可能的最大整数： %lld或%llu 。 %ju在printk格式化核心文件lib/linux/vsprintf.c下不可用。