debugfs api，例如debugfs_create_dir表示
如果内核中未启用debugfs，则返回值-ENODEV。检查此值是不明智的，而是检查NULL或！NULL，以消除调用代码中#ifdef的需要。
但为什么不明智？你能给我一些关于eliminate the need for #ifdef in the calling code的例子吗？
答案 0 :(得分：1)
呀。这个建议毫无意义。如果未启用CONFIG_DEBUG_FS，则返回值-ENODEV（强制转换为指针）。这显然不是NULL，但也不能用作有效指针。
最好是在返回值上使用IS_ERR_OR_NULL（ptr）。如果未定义CONFIG_DEBUG_FS，则将捕获-ENODEV返回。如果定义了CONFIG_DEBUG_FS ，但调用失败，则返回NULL。这种方式可以处理任何一种可能性。
答案 1 :(得分：1)
可以将-ENODEV解释为成功，直到使用dentry返回除了删除它（ debugfs_remove ）并将其用作另一个文件的目录（ debugfs_create _ -family）之外的其他内容）。当正确禁用CONFIG_DEBUG_FS时，所有这些函数都处理大小写。
这就是为什么它只用于检查NULL或！NULL。
在极少数情况下，当debugfs_create _ *（）返回的dentry被明确引用时（例如，对于访问inode的私有数据），只需检查第一个此类调用不返回-ENODEV就足够了。
答案 2 :(得分：1)
编写代码的一种方法是：
#ifdef CONFIG_DEBUG_FS
< ... do your debugfs stuff ... >
#endif
我猜这就是文档的含义。
许多内核开发人员认为在代码中放置太多#ifdef - #endif对是丑陋的（＆＃34;多毛＆＃34;）。 See this kernel doc。
来自内核编码样式文档的相关代码段： ＆＃34;喜欢编译整个函数，而不是函数或函数的一部分 表达的一部分。因素而不是将ifdef放入表达式中 将部分或全部表达式转换为单独的辅助函数并应用 以该功能为条件。＆＃34;
鉴于此，遵循它的建议，如果您希望不使用#ifdef，那么请选择已发布的答案。