В данной заметке хочу оставить пару комментариев к примеру работы с файловой системой /proc из вышеприведенного мануала. Во время познания материала обнаружил некоторые несостыковки и вещи не совсем поясненные до конца, так что тут попытаюсь внести немного больше ясности для тех, кто начнет топать этим путем. Изучая программирование модулей ядра Linux, познавая (ИМХО, хороший) труд "The Linux Kernel Module Programming Guide" заметил несколько несостыковок при впитывании информации в разделе 7 "Файловая система /proc".  Сразу поясню: так как напрятаться было лень читал книжку в переводе от команды RUVDS (за что им большое спасибо), но перевод, кажется, стар, поэтому параллельно всматривался в оригинал, датируемый "May 2, 2023" - вроде бы как свежак). Условимся, что далее по тексту "RU" будет означать переведенную версию, "EN" - оригинал. Ниже привожу код с примером "procfs3.c", как он есть в RU. Первое, что ввело смуту - функция "procfs_read". Получается, чтобы прочитать, например, cat-ом нужно этот самый cat вызвать 2 раза для обновления статической переменной (напомню, 0 возвращается в этой функции, когда чтение закончено, а тут 0 вернется на 2-й вызов).  Честно говоря, при вызове "procfs_write" не очень понятно, почему меняется именно внутренняя переменная "procfs_buffer_size", а не пользовательский "len".  И убило меня применение "remove_proc_entry". Убило, потому чтобуквально в предыдущем примере вроде бы как для тех же вещей было использовано "proc_remove".  Решил заглядуть в EN.  Заглянув в оригинал я понял, что он действительно посвежее и доработаннее: Тут видно, что "procfs_read" обрабатывается более правильнее, да и в целом код цивилизованнее - обрабатывает некоторые ситуация, проверки всякие добавлены. Казалось бы - бинго! На это можно остановиться! Проблема старой версии! Но терзавший меня "remove_proc_entry" все еще уверенно сияет в исходном коде без всяких пояснений от авторов. Ничего не понял, полез на википедию... И действительно, каким-то немыслимым футуристичным образом нашел доку, где есть фраза: Deprecated create_proc_entry.  Note that the above article uses create_proc_entry which was removed in kernel 3.10. Current versions require the following update: Больше ничего дельного не увидел (наверное мало искал, надеюсь, кто-то умный подскажет что-то более конкретное).  Так как я глуп и неопытен, то связал "create_proc_entry" & "remove_proc_entry", как 1й, "depricated" интерфейс для создания/удаления точки входа в /proc, а "proc_create" & "proc_remove", как 2-й, более свежий. Вернее, кто это такой - очень даже понятно, установка размера файла в /proc. Но для чего она нужна? Итак, пусть в функции "procfs3_init", как в примере EN, будет установлен размер файла, равный 80, тогда в выводе "ls -lah /proc/procfs_3_note" будет явно указан этот заданный размер файла. Но на что он влияет? Попробуем провести эксперимент. Скомпилируем программу с размером файла = 1 и установим модуль ядра.  Размер файла = 1, но, как и следовало ожидать запись и чтение ограничено только внутренним буфером: Т.е. размер файла влияет совсем не на это. Как сказал @jcmvbkbc(мерси): Для того, чтобы дать возможность обращаться к файлу из /proc с ненулевого смещения... Окей, попробуем. Рекомпиляем проект под размер 10 байт, загружаем вводим эхом последовательность 0123456789.    Пытаемся считать первые пару байт: Все хорошо, теперь считаем из середины. Упс.. Кажется что-то не то. Адреса (колонка слева) изменены, но данные остались те же. Дело в том, что параметр -s утилиты hexdump позволяет задать смещение относительно начала файла для чтения. Этот параметр в функцию модуля ядра поступает, как offset/off в примере выше, но, если вглядеться, то видно, что в коде изменяются значения сдвигов, но сами значения не влияют на функции передачи данных в/из юзерленд/а. Исправим: Тестим, теперь похоже на правду: Но все же разбираться начали с proc_set_size. (Напомню, сейчас установлен в 10) Попробуем установить сдвиг > 10: Пусто) Заглянем в лог и видим, что функция чтения даже не была вызвана: Судя по всему, стоит передавать в proc_set_size размер внутреннего буфера, по крайней мере в тривиальных случаях. После всех поисков и разбирательств, написал модуль по образу и подобию вышеуказанных, но с добавлением некоторых комментариев и исправлений, которых нехватало мне. Может быть когда-то кому-то это чем-то поможет, спасибо.