Чтобы добавить к ответу caf, упоминающему vfs_readdir(), чтение и запись в файлы из ядра считаются небезопасными (за исключением /proc, который действует как интерфейс для внутренних структур данных в ядро.)
Причины хорошо описаны в этой статье linuxjournal , хотя они также обеспечивают возможность доступа к файлам. Я не думаю, что их метод может быть легко изменен для работы с каталогами. Более правильным подходом является обращение к файловой системе ядра inode записей, что и делает vfs_readdir.
Inode - это объекты файловой системы, такие как обычные файлы, каталоги, FIFO и другие.
звери. Они живут либо на диске (для файловых систем блочных устройств)
или в памяти (для псевдофайловых систем).
Обратите внимание, что vfs_readdir() ожидает параметр file *. Чтобы получить структурный указатель file из дескриптора файла пользовательского пространства, вы должны использовать таблицу дескрипторов файлов ядра.
В документации по файлам kernel.org сказано следующее:
Для поиска файловой структуры по заданному файлу читатель
должны использовать API fcheck() или fcheck_files(). Эти
позаботьтесь о барьерных требованиях из-за поиска без блокировки.
Пример:
rcu_read_lock();
file = fcheck_files(files, fd);
if (file) {
// Handling of the file structures is special.
// Since the look-up of the fd (fget() / fget_light())
// are lock-free, it is possible that look-up may race with
// the last put() operation on the file structure.
// This is avoided using atomic_long_inc_not_zero() on ->f_count
if (atomic_long_inc_not_zero(&file->f_count))
*fput_needed = 1;
else
/* Didn't get the reference, someone's freed */
file = NULL;
}
rcu_read_unlock();
....
return file;
atomic_long_inc_not_zero() определяет, равен ли refcounts нулю или
обнуляется во время приращения. Если это произойдет, мы потерпим неудачу fget() / fget_light().
Наконец, взгляните на filldir_t, второй тип параметра.