Как общаться с устройствами ввода вывода на Си в linux?

Question

[Никита]

Есть порты в /proc/ioports, что мне изучить, что бы понимать как общаться с устройствами по этим портам на Си, и разрешит ли это ядро? Нужен ли язык ассемблера для этого или можно на чистом Си?

Comments

[pfg21]

писать модуль ядра :)
никому другому ядро не даст работать напрямую с памятью.
можно на си, можно на расте.

[Никита]

pfg21, понял, спасибо

[mayton2019]

Язык Си тоже позволяет внуть кода вставлять ассемблерные вставки. Правда ассемблер там - не самый
комфортный. Но по возможностям вроде-бы достаточно чтоб делать все что надо.

[pfg21]

Nitaki58, вариант2: использовать имеющийся едрёный модуль и работать с выведенными в пространство пользователя станадартизированными интерфейсами.

[jcmvbkbc]

никому другому ядро не даст работать напрямую с памятью.

pfg21, man ioperm, google mmap /dev/mem

[pfg21]

jcmvbkbc, чет костыль какойто :) из мана по ioperm
ЗАМЕЧАНИЯ
Libc5 рассматривает данную функцию как системный вызов, и поэтому в есть ее прототип. В Glibc1 этого прототипа нет. В Glibc2, в и в этот прототип есть. Не используйте второй вариант, он существует только в версии i386.

ну а /dev/mem "не прямой путь" :) в остальном согласен.

[jcmvbkbc]

/dev/mem "не прямой путь"

pfg21, в чём заключается его "непрямота"?

[pfg21]

jcmvbkbc, ты работаешь с памятью опосредовано :) через драйвер /dev/mem.

[jcmvbkbc]

ты работаешь с памятью опосредовано :) через драйвер /dev/mem

pfg21, ты создаёшь отображение памяти через драйвер. К отображённой памяти ты обращаешься напрямую, процессорными инструкциями.

[Никита]

pfg21, возможно я некорректно поставил вопрос, прошу прощения, так же скорее всего я не понял что находиться в этой директории, я имею ввиду как можно заставить например вентилятор крутиться медленнее, индикаторы на клавиатуре мигать поочередно и т.п., и если вам не сложно, то не могли бы вы поделится темами которые надо изучить для этого.
И я буду невероятно благодарен если порекомендуете книги/статьи на эти темы

[pfg21]

jcmvbkbc, неа, ваапче не так :)
mmap отображает фал на произвольную память, котрую ему выдал менджер памяти. ты записываешь в эту область, mmap отлавливает это изменение и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь, выявляет подстрочку /dev и направляет его в драйвер udev ответственный за этот путь. udev перенаправляет запрос в драйвер, ответственный за /dev/mem, и только он разбирает файловый запрос и пишет напрямую в указанный адрес физической памяти.
это конечно докапывание до тонкостей, но вот так :)

[pfg21]

Nitaki58, если есть познания в програмировании (скорей всего в С, но сейчас в ядро потихоньку впускают rust), то разбираешься с железом.
ищешь уже работающие аналогичные драйвера в завалах исходников kernel. разбираешься как они работают, скорее всего они формируют стандартные интерфейсы управления в соответствующих подпапках /sys.
к примеру /sys/class/leds для светодиодиков, у меня там три ссылки на устройства светодиодиков клавиатуры.
переделываешь под свой ноутбук. компилируешь, тестируешь, допиливаешь и выкладываешь на тест.
после теста несколькими сторонними пользователями формируешь патч на внедрение твоей работы в ядро линукса.
имхо так будет сложно, долго, но правильно :)
книг статей навалом. тот же сборник Можете подсказать практичный список литературы по разработке драйверов для linux и вообще по работе в ядре? от jcmvbkbc

[Никита]

pfg21, понял, спасибо большое, ставлю курс на изучение драйверов!

[jcmvbkbc]

mmap отображает фал на произвольную память, котрую ему выдал менджер памяти. ты записываешь в эту область, mmap отлавливает это изменение и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь, выявляет подстрочку /dev и направляет его в драйвер udev ответственный за этот путь. udev перенаправляет запрос в драйвер, ответственный за /dev/mem, и только он разбирает файловый запрос и пишет напрямую в указанный адрес физической памяти.

pfg21, прикольная фантазия.
А теперь о реальности: когда ты открываешь файл /dev/mem и передаёшь его fd в системный вызов mmap, в ядре вызывается функция mmap_mem зарегистрированная здесь. Эта функция, как можно увидеть здесь, вызывает remap_pfn_range для выделенного участка виртуальной памяти, а в качестве параметра pfn, определяющего номер страницы физической памяти, как написано здесь, передаёт vma->vm_pgoff, т.е. смещение, переданное mmap, но выраженное в страницах. Т.е. не "произвольную память, котрую ему выдал менджер памяти", а вполне конкретную физическую память, которую ты попросил в вызове mmap.

[pfg21]

jcmvbkbc, согласен. этих подробностей не знаю.
однако один фиг, запись значения в память, посредством /dev/mem, проходит кучу прослоек.

[jcmvbkbc]

pfg21, выбери что-нибудь одно, либо

неа, ваапче не так :)

либо

согласен. этих подробностей не знаю.

И то и то вместе смотрится как-то крипово, как будто ты не человек разумный, а бот какой-то.

запись значения в память, посредством /dev/mem, проходит кучу прослоек

pfg21, запись значения в память происходит напрямую, нет никаких прослоек.

[pfg21]

jcmvbkbc, не все знаю, чего в этом криповатого ??
Не погромист, с системными функциями линукс не ковырялся.
Цепочку действий для записи значения в память с помощью спец.файла /dev/mem я привел чуть выше.
Приведи свою.
Я сильно сомневаюсь что в функции mmap есть хук под файл /dev/mem, позволяющий мапить /dev/mem в память с совпадающими диапазонами и тем самым записывать значение напрямую в ram, без указанной цепочки

[jcmvbkbc]

не все знаю, чего в этом криповатого ??

pfg21, чрезмерно уверенный тон ответов. "Не всё знаею", а пишешь -- как будто экспертным мнением делишься. И не в первый раз, и не только по этому топику.

Цепочку действий для записи значения в память с помощью спец.файла /dev/mem я привел чуть выше.

Это не "ты привёл цепочку действий", это ты какую-то бредовую фантазию привёл, без каких либо документальных потверждений.

Приведи свою.

Если внимательно прочитать этот комментарий, то он как раз об этом. Но и без того, любая книжка по внутренностям линукса это делает. Половина главы 15 LDD, например, буквально об этом.

Я сильно сомневаюсь что в функции mmap есть хук под файл /dev/mem

Хука под файл /dev/mem конечно нет. Есть поле mmap в структуре file_operations, позволяющее любой файловой системе или драйверу предоставить свою реализацию mmap для файлов которые они обслуживают. Опять же, любая книжка по внутренностям ядра об этом рассказывает.

[pfg21]

Это не "ты привёл цепочку действий", это ты какую-то бредовую фантазию привёл, без каких либо документальных потверждений.

где здесь бредовость ?? :)
стандартная цепочка действий работы с файлом (про хук чуть ниже, считаем что его нет).
mmap работает с файлом, т.е. формирует файловые операции, дальше цепочка обработки файла станадартна. в каком месте бредовость ??

у тебя рассказано как работает mmap, это имеет смысл если для /dev/mem написан хук, позволяющий исключить все файловые операции и напрямую записывать в память. но это потребует наличие в хуке кода обработки доступов пользователя к /dev/mem. сильно сомневаюсь что такой хук будет внедрен, смысл в нем ??

[jcmvbkbc]

в каком месте бредовость ??

pfg21, в каждом предложении. Конкретно:

mmap отлавливает это изменение…

когда пользователь обращается к отображённой памяти, вызов mmap уже давно закончился и не может "отловить это изменение". Ты имел в виду подсистему виртуальной памяти?

…и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь

Т.е., я правильно понимаю, мы отобразили файл в память (а это значит, откыли его перед этим), а теперь "mmap, отловивший изменения в памяти" посылает запрос, в котором фигурирует путь до этого файла? А если файл тем временем удалили? Или переименовали? Или удалили и создали другой файл с таким же именем на его месте?

выявляет подстрочку /dev

Т.е., я правильно понимаю, что по-твоему /dev/mem работает только пока он в /dev, а если его перенести в какое-нибудь другое место, то он работать перестанет?

и направляет его в драйвер udev ответственный за этот путь

Что это за термин, "драйвер udev"? devtmpfs?

[jcmvbkbc]

это потребует наличие в хуке кода обработки доступов пользователя к /dev/mem.

pfg21, Нет, не потребует. Потому что проверкой доступа занимается вызов open, которым файл открывают.

сильно сомневаюсь что такой хук будет внедрен, смысл в нем ??

Я выше приводил ссылки в код ядра реализующий mmap для /dev/mem, в чём ты конкретно сомневаешься, я не понял?

[pfg21]

когда пользователь обращается к отображённой памяти, вызов mmap уже давно закончился и не может "отловить это изменение". Ты имел в виду подсистему виртуальной памяти?

jcmvbkbc, хз, я не знаю работы mmap. знаю лишь то что изменения в памяти куда с помощью mmap замаплен файл, вызовет каким-либо запрос на изменения файла.

А если файл тем временем удалили? Или переименовали? Или удалили и создали другой файл с таким же именем на его месте?

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

Т.е., я правильно понимаю, что по-твоему /dev/mem работает только пока он в /dev, а если его перенести в какое-нибудь другое место, то он работать перестанет?

я сталкивался с ним только по стандартному пути /dev/mem
можно ли еще где создать не знаю. да и в контексте вопроса сие не имеет значения.
в любом случае это не будет прямым изменением памяти.

Нет, не потребует. Потому что проверкой доступа занимается вызов open, которым файл открывают.

полностью согласен.
а если есть хук в mmap под /dev/mem или еще где, это потребует в хуке кода спец.кода для обработки доступа.

Я выше приводил ссылки в код ядра реализующий mmap для /dev/mem, в чём ты конкретно сомневаешься, я не понял?

код, реализующий mmap под /dev/mem, не приводил :)

[jcmvbkbc]

…но это совсем не в тему

…в контексте вопроса сие не имеет значения.

pfg21, твой последний вопрос был, я напомню, "в каком месте бредовость", в контексте этого вопроса это имеет непосредственное значение.

код, реализующий mmap под /dev/mem, не приводил :)

Я из этого могу сделать только вывод о том, что ты мои ответы не читаешь. Потому что я приводил ссылку на этот код, вот в этом комментарии: "Эта функция, как можно увидеть здесь, вызывает…". Как тебя после этого воспринимать хоть сколько-нибудь серьёзно -- непонятно.

[pfg21]

jcmvbkbc, читаю.
где в указанных тобой ссылках на код имеется хук обрабатывающий как-либо отдельно /dev/mem ??

Т.е. не "произвольную память, котрую ему выдал менджер памяти", а вполне конкретную физическую память, которую ты попросил в вызове mmap.

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

[jcmvbkbc]

pfg21, функция mmap_mem -- этот самый "хук". Она зарегистрирована здесь как обработчик mmap в mem_fops, mem_fops указаны как fops в массиве devlist для устройства с минорным кодом DEVMEM_MINOR, этот массив обрабатывается здесь, где регистрируются устройства с мажорным кодом MEM_MAJOR. Устройство с кодом 1, 1 -- это /dev/mem и есть, как можно увидеть здесь

[pfg21]

jcmvbkbc, т.е. ты утверждаешь что mmap при мапинге /dev/mem будет напрямую писать в физическую память ??
отлично, тогда получается любой пользователь может получить доступ к любому участку физической памяти без каких-либо проверок, только за'mmap'ив /dev/mem в своей проге ??

[jcmvbkbc]

ты утверждаешь что mmap при мапинге /dev/mem будет напрямую писать в физическую память ??

pfg21, mmap не будет никуда писать. Но mmap может отобразить любую область физической памяти в адресное пространство процесса для прямого доступа.

тогда получается любой пользователь может получить доступ к любому участку физической памяти без каких-либо проверок, только за'mmap'ив /dev/mem в своей проге ??

Почти. Любой пользователь который может открыть /dev/mem.

[pfg21]

jcmvbkbc, хз, мудрено. пофиг :) пусть будет так.

Answer 1

[Никита]

Linux Device Drivers: https://lwn.net/Kernel/LDD3