能否通过inotify或epoll监控ConfigFS文件？

1. inotify 支持情况 #

ConfigFS 不原生支持inotify。作为内核虚拟文件系统，它的多数文件内容是动态生成的，并非基于常规磁盘inode结构，而inotify依赖的inode变更通知机制在这里无法正常触发——你用inotify监控ConfigFS文件，基本收不到预期的变更事件。

2. epoll 支持情况 #

epoll也无法直接监控ConfigFS文件的内容变更。epoll对文件的监控依赖描述符的可读/可写事件，但ConfigFS文件大多是只读或仅在特定操作时生成内容，不会主动触发可读事件。只有极少数内核驱动特殊实现了poll接口的ConfigFS属性文件可能支持epoll，但这种情况非常罕见，不具备通用性。

3. 可行的非轮询替代方案 #

• 监听netlink uevent事件：ConfigFS在配置项或设备发生变更时，通常会通过netlink发送uevent消息。你可以在用户态监听netlink通道，根据消息里的路径或标识判断目标ConfigFS文件是否变更。
• 使用libudev库：libudev封装了uevent的处理逻辑，能更便捷地监听ConfigFS相关的配置/设备变更，不用自己处理底层netlink通信细节。
• 自定义内核通知（若有能力）：如果允许修改内核代码，可以在ConfigFS的相关操作逻辑里添加自定义通知（比如用eventfd向用户态发信号），但这需要内核开发经验。

注意事项 #

不同Linux内核版本对ConfigFS的特性支持有差异，建议先确认你的内核版本是否有相关扩展支持；如果以上方案都不适用，只能退而求其次采用低频率轮询（比如1-5秒间隔），尽量降低系统开销。

内容的提问来源于stack exchange，提问作者ADecostre