事件linux
‘壹’ udev 入门：管理设备事件的 Linux 子系统
udev是Linux环境中用于监控和管理设备事件的核心子系统。以下是关于udev入门的简要介绍：
udev的基本功能：
- 监控设备事件：udev负责监控系统中设备的事件，如新设备的连接、断开等。
- 管理设备节点：udev会根据设备的事件和设备信息创建或删除相应的设备节点。
记录设备插入事件：
- 可以编写脚本，利用时间戳记录设备插入事件到日志文件中，如/tmp/udev.log。
- 使用udevadm monitor命令可以实时监控设备动态，如U盘的添加事件。
定制规则，识别特定设备：
- 在/etc/udev/rules.d目录下创建规则文件，用于定义特定设备的事件触发动作。
- 规则文件中可以指定子系统、动作、内核设备名等属性，以匹配特定设备。
- 例如，为所有新插入的块设备执行特定脚本，或者为特定厂商和型号的U盘执行特定操作。
自动化设备备份：
- 可以创建规则，为新插入的U盘创建符号链接，并触发备份脚本。
- 符号链接策略确保不会干扰设备的正常挂载，同时备份脚本负责将数据复制到指定路径。
udev规则的编写：
- udev规则由一系列键值对组成，每个键值对都描述了设备的某个属性。
- 常用的键值对包括SUBSYSTEM、ACTION、KERNEL、ATTRS等。
- 规则中的RUN键用于指定当规则匹配时要执行的脚本或命令。
udev的安全与效率：
- udev允许为设备管理设置安全、高效的策略，确保数据安全和备份流程的可靠性。
- 通过精确控制设备行为，udev可以减少不必要的系统资源消耗，提高系统性能。
总之，udev是Linux系统中非常重要的设备管理子系统，通过编写规则和脚本，可以实现设备事件的自动监控和管理，提高系统的灵活性和安全性。
‘贰’ Linux文件事件监控之Fanotify [一]
Linux文件事件监控之Fanotify
在Linux系统中，文件事件监控从简单的监听发展到更强大的监控，这一过程中经历了不少改进。自2001年引入的dnotify作为早期的文件事件监听机制，虽在2.4版本内核中初现，但由于其局限性，如只能监控目录且采用信号机制，导致功能有限。
随后，inotify于2005年在2.6.13内核版本中亮相，它不仅能够监控目录，还能监听普通文件产生的事件，并采用事件队列的形式向监听进程发送信息。尽管inotify相对完善，但其“notify”功能仅能让监听进程知道事件发生，并不能主动介入改变事件行为。
为解决此问题，2.6.36内核中引入了fanotify，实现了从“监听”到“监控”的转变，允许监听进程介入并改变文件事件的行为。fanotify通过简单的调用接口，提供两个主要API，分别用于设定监控模式以及展开具体配置。
fanotify的使用灵活性较高，通过fanotify_init()函数设定监控模式，可以指定监听进程在文件内容准备就绪时介入，或仅接收通知。在实际应用中，监听进程通过fanotify_mark()函数配置监控的文件路径、事件类型以及感兴趣的对象列表，以实现对文件事件的精确控制。
虽然fanotify并非内核模块，也没有对应的设备文件，但它在抽象层面可以被视为特殊的文件，与之交互的方式类似于open()系统调用，通过fcntl.h头文件中的相关参数进行操作。获得file descriptor后，监听进程可以利用fanotify_mark()函数进行文件事件监控配置。
文件事件监控的关键在于与文件数据结构的关联，通过指向inode结构体中对应元素的fsnotify_mark_connector指针实现。这一设计类似于epoll机制，fanotify_init()和epoll_create()功能相似，用于监听文件事件，而fsnotify作为后端组件，负责接收事件并将信息传递给前端监听进程。
fanotify与epoll的层级关系体现在使用场景中，fanotify通过fsnotify与监听进程交互，实现更精细的文件事件控制。在具体实现中，fanotify通过在do_dentry_open()函数前的hook机制，与Linux安全模块（如SELinux）协同工作，进一步增强文件事件的管理能力。
fsnotify作为后端组件，接收文件事件并将其传递给前端监听机制，包括dnotify、inotify和fanotify。通过提取共通之处，fsnotify简化了文件事件管理的复杂性，提高了整体效率。在实现中，fsnotify维护一个事件队列，根据各个前端配置的mask，在对应的目标队列中存放事件指针，实现高效的信息传递。
了解fanotify的原理与应用，有助于开发者构建更精细、高效的文件监控系统，为各类应用提供强大的文件事件处理能力。