kernel (VFS)

generation counter, используется по разному.

напр, см fs/ext2/dir.c:ext2_readdir()

типа: когда изменяется содержимое каталога ++inode->i_version

следующий вызов readdir() может это заметить:

        if (file->f_version != inode->i_version) {
                revalidate();
                file->f_version == inode->i_version;
        }

см также fs/pipe.c, fs/seq_file.c и вообще grep.

забыл сказать,

> file->f_version = ++event

забудьте, это 2.4, в 2.6 'event' отсутствует.
оно и в 2.4, кажется, не нужно.

2idle:


я не могу забыть так как программирую для данной ветки!

И еще, grep'ом я этих учатков кода нарыл не мало, поэтому и спрашивую, мспользуется ли эта информация ниже- или вышележащими модулями VFS? Вообще если она не используется, для чего тогда эти поля и ++event?!

я вас не понимаю.

> мспользуется ли эта информация ниже- или вышележащими модулями VFS?

ну а я-то откуда могу знать, где ваш код находится и что делает ?

> grep'ом я этих учатков кода нарыл не мало,

так вот и смотрите!

> для чего тогда эти поля и ++event?!

примеры использования f_version я вам привел.

event, в сущности (он ведь всегда использовался как
++event, если я не ошибаюсь) - дешевое "случайное"
число, каждый раз разное.

Этих примеров grep'ом я нарыл много. И примеры эти касаются VFS и фаловых систем.

МНЕ _НЕ_ понятно зачем различные фаловые системы делают ++event если на их уровне (файловых) систем они не используются. И спрашивал, используется ли на уровне буферного кэша или еще где в VFS _то_что_ утановила файловая система или скажем VFS при выполнении sys_open??????!!!!!!!!!

> ??????!!!!!!!!!

o! как!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :)

я еще раз (последний) попытаюсь обьяснить. может я тупой,
и не понимаю вопроса.

event _прямого_ отношения к vfs не имеет. использовался
как очень дешевый (не такой уж, в SMP случае) генератор
"случайного" и "всегда разного" числа, это я уже говорил.

fs_version - generation counter, примеры его использования
я тоже уже приводил. инициировался он из ++event.