fsnotify 真的需要全局列表扫描吗？

发布于 2024-12-03 01:05:47 字数 807 浏览 0 评论 0原文

我正在研究linux内核代码，更具体地说是fs/notify/fsnotify.c中的文件系统通知...AFAIK，每个inode现在都给出一个“标记”列表，每个标记都引用一个监听通知的“组”在该索引节点上。在VFS代码中，通过使用fsnotify(triggering_inode, REASON|OTHER_REASON,additional_parameters...)

在该fsnotify()函数中引发通知，我很困惑特别是

 list_for_each_entry_rcu(group, &fsnotify_groups, group_list) {
     if (test_mask & group->mask) {
        if (!group->ops->should_send_event(group, to_tell, mask))
                continue;
            // more code that sends notification
     }
 }

，fsnotify_groups 显然是 (fsnotify.h) 一个记录所有组的全局列表。我最好的选择是内核开发人员知道他们在这里做什么，并且我错过了一个关键点，该点阻止我们仅使用 foreach(mark:inode->fsnotify_mark_entry) { g=mark->linked_group; } 这肯定会随着系统上通知侦听器的数量而更好地扩展。

周围有人知道为什么这里仍然使用全局列表吗？

原文

I'm studying the linux kernel code, more specifically the filesystem notifications within fs/notify/fsnotify.c ... AFAIK, each inode is now given a list of "marks", each one referencing a "group" which listens to notification on that inode. In the VFS code, notifications are raised through the use of fsnotify(triggering_inode, REASON|OTHER_REASON, additional_parameters...)

Within that fsnotify() function, I'm puzzled by

 list_for_each_entry_rcu(group, &fsnotify_groups, group_list) {
     if (test_mask & group->mask) {
        if (!group->ops->should_send_event(group, to_tell, mask))
                continue;
            // more code that sends notification
     }
 }

Especially, by the fact that fsnotify_groups is obviously (fsnotify.h) a global list where all the groups are recorded. My best bet is that kernel developers know what they're doing here, and that I miss a critical point that prevent us from just using foreach(mark:inode->fsnotify_mark_entry) { g=mark->associated_group; } that would definitely scale better with the numbers of notification listeners on the system.

Anybody around has a clue why things still use the global list here ?

分享到QQ

分享到微博