Как открыть каталог на уровне ядра с помощью дескриптора файла для этого каталога?

Я работаю над проектом, где я должен открыть каталог и прочитать файлы / каталоги внутри уровня ядра. Я в основном пытаюсь выяснить, как ls реализуется на уровне ядра.

Прямо сейчас я выяснил, как получить файловый дескриптор для каталога с помощью sys_open() и O_DIRECTORY flag , но я не знаю, как читать fd, который я получаю. Если у кого-нибудь есть какие-либо советы или другие предложения, я бы это оценил. (Имейте в виду, что это нужно делать на уровне ядра).

Редактировать: Короче говоря, Для школьного проекта я реализую атрибуты файла / каталога. Где я храню атрибуты – это скрытая папка на том же уровне файла с заданным атрибутом. (Так что файл в Desktop / MyFolder имеет папку с атрибутами Desktop / MyFolder / .filename_attr). Поверьте мне, я не хочу вмешиваться в kernel ​​для funsies. Но причина, по которой мне нужно читать директорию на уровне ядра, заключается в том, что она отличается от спецификации проекта.

Чтобы добавить к ответу в кафе, в котором упоминается vfs_readdir() , чтение и запись в файлы из ядра vfs_readdir() , считается небезопасным (за исключением /proc , который действует как интерфейс к внутренним структурам данных в ядре).

Причины хорошо описаны в этой статье в linuxjournal , хотя они также предоставляют взломать доступ к файлам. Я не думаю, что их метод может быть легко изменен для работы в каталогах. Более правильный подход – это доступ к записям inode в файловой системе ядра, что и делает vfs_readdir .

Inodes – это объекты файловой системы, такие как обычные файлы, каталоги, FIFO и другие животные. Они живут либо на диске (для файловых систем блочного устройства), либо в памяти (для псевдо файловых систем).

Обратите внимание, что vfs_readdir() ожидает параметр file * . Чтобы получить указатель file структуры из дескриптора файла пространства пользователя, вы должны использовать таблицу дескриптора файла ядра.

Документация файлов kernel.org гласит следующее:

Для поиска файловой структуры с учетом fd читатель должен использовать либо fcheck() либо fcheck_files() API. Они заботятся о требованиях к барьеру из-за отсутствия блокировки. Пример :

  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 , второй тип параметра.

Вероятно, вы хотите vfs_readdir() из fs/readdir.c .

В общем, хотя код ядра не читает каталоги, код пользователя делает.