Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
Вот таких бы топиков побольше!
Это мой первый топик на хабре. Рад что вам понравилось :)
и таких бессмысленных комментариев поменьше
Да смотреть тошно на всю ту срань, что на главной развели.
Содержание главной зависит только от нас. Достаточно каждому выставлять в день по паре десятков плюсов-минусов, чтобы сделать «Хабр опять торт»
Стараемся в меру сил, но не всегда хватает терпения.
Мотивирует!
Это афигенно интересно! Прошу Вас продолжайте дальше!
P.S. Простите за эмоции просто давно здесь такого не видел.
P.S. Простите за эмоции просто давно здесь такого не видел.
Очень понравилась статья. Но стоит исправить мелкие опечатки. Однозначно в избранное.
«LKM для 2.6 отличается от 2.4» Где можно почитать о различиях?
Почитать можно всё в том же LKMPG. Цитата: «LKMPG (Linux Kernel Module Programming Guide), имеющее версию 2.4.x относится к ядру 2.4.x, а LKMPG 2.6.x — к ядру версии 2.6.x.»
Большое спасибо.
Главное, чтобы новички не закопались с этой замечательной книгой, поскольку многие примеры не работают на текущих ядрах без небольших изменений. Это касается всего, что связано с очередями worqueue, небольшие изменения в примере по прерываниям, перехват системных вызовов потребует элементарного поиска sys_call_table и знания механизмов защиты памяти. Да и прототипы функций многих API ядра часто меняются.
Для того, чтобы совсем не потеряться в ядерном мире и быть в струе, быстро находя изменения, новичкам можно посоветовать the Linux Cross Reference
Для того, чтобы совсем не потеряться в ядерном мире и быть в струе, быстро находя изменения, новичкам можно посоветовать the Linux Cross Reference
Хороший, понятный топик. Ничего лишнего.
Спасибо, Вам стоит задуматься над идеей написания «Linux Kernel for Dummies» :)
Спасибо большое. Ваша статья мне очень помогла. Насколько я понял, Ваше устройство не связано с реальнім физическим устройством. Как добавить в систему свое физическое устройство? (Укажите хоть порядок действий)
При обращении к файлу устройства вызываются функции-обработчики действий открытия, закрытия, чтения и записи файла, которые вы можете задать для него, используя структуру file_operations. Вы можете получать данные, которые пользовательская программа записывает в ваш файл устройства, соответствующим образом реагировать, отправлять часть данных реальному устройству через порты ввода-вывода, обрабатывать прерывания от реального устройства и отдавать ответ пользовательскому приложению через тот же файл устройства.
Для реальных проектов иногда лучше подходит обработка ioctl вызовов. Хотя и просто через файл всегда можно реализовать.
Для реальных проектов иногда лучше подходит обработка ioctl вызовов. Хотя и просто через файл всегда можно реализовать.
Да, Вы правы, /dev/test не связано ни с каким реальным устройством. Насчёт написания настоящего драйвера — советую почитать «Linux Device Drivers» от O'Reilly
Разницы никакой нет, будь то физическое или виртуальное устройство. Файл устройства создается именно так, как это представил автор. Разница в том, что в случае с реальным устройством, вы будете использовать этот файл для связи с пространством пользователя, а остальная работа по взаимодействию с устройством в пространстве ядра ложится на ваши плечи.
>физическое или виртуальное устройство. Файл устройства создается именно так
как правило, регистрируется не файл устройства напрямую, а *устройство* определенного класса (реализующее определенный интерфейс) через соответствующую подсистему.
или, что еще правильней, регистрируется драйвер, который работает с устройствами определенной модели и ждущий, пока появится новое железо с определенными параметрами (в usb — vid, pid, class).
хотите простых примеров — смотрите в drivers/input/ или tty, там все красиво, понятно и по делу
как правило, регистрируется не файл устройства напрямую, а *устройство* определенного класса (реализующее определенный интерфейс) через соответствующую подсистему.
или, что еще правильней, регистрируется драйвер, который работает с устройствами определенной модели и ждущий, пока появится новое железо с определенными параметрами (в usb — vid, pid, class).
хотите простых примеров — смотрите в drivers/input/ или tty, там все красиво, понятно и по делу
TTY был описан и в Linux Device Drivers 3 довольно подробно. А вот от примеров по usb или, так или иначе связанных с сетью, не отказался бы. Спасибо за полезное начинание.
с usb самое главное — понять терминологию. дальше все просто до неприличия и нормально решается даже из юзерспейса.
если из ядра — поймать устройство через vid/pid и повесить коллбеки на приход пакетов по нужным портам (ep).
больше мороки будет с обработкой данных и тем классом устройства, которое этот драйвер реализует, а сама отправка-получка там тривиальна.
если из ядра — поймать устройство через vid/pid и повесить коллбеки на приход пакетов по нужным портам (ep).
больше мороки будет с обработкой данных и тем классом устройства, которое этот драйвер реализует, а сама отправка-получка там тривиальна.
Хабру не хватает таких постов.
Спасибо.
Спасибо.
Классная статья! Спасибо!
за такие отступы и пробелы в LKML дают канделябром по коммит-аццессу
Отличная статья. Очень интересно.
Ребят, не все пользователи Linux станут писать драйвер, и я думаю именно для таких целей, было бы неплохо сделать блог под названием «Linux Hardcore» или «Linux для профессионалов» (хоть и уже есть целых два блога Linux не для всех, но они не подходят по тематике) и выкладывать там статьи похожего содержания, а также статьи про тонкую настройку веб серверов, про использование консоли в профессиональных целях и т.п. А блог «Linux для всех» оставить для статей общего характера и для пользователей абсолютно любого уровня.
Спасибо за статью.
Хотелось бы в следующей статье увидеть разработку драйвера для какого нибудь простейшего реального устройства :)
Хотелось бы в следующей статье увидеть разработку драйвера для какого нибудь простейшего реального устройства :)
Можно добавить файл устройства в /dev сразу после регистрации модуля.
$ man 2 mknod
$ man 2 mknod
GregKH благодарен вам за статью )
Шикарная пятница по топикам вышла! Это очередной бриллиант в сегодняшней коллекции.
Скажем «НЕТ» пятничным сиськам на хабре! -)
Скажем «НЕТ» пятничным сиськам на хабре! -)
Хороший мануал по теме
l4u.jinr.ru/docs/add04/lkmpg.html
l4u.jinr.ru/docs/add04/lkmpg.html
отличная статья.
правда, эта информация была доступна еще 10 лет назад и, по большому счету, ничего со времен 2.0 и 2.2 не изменилось в работе с символьными устройствами.
все равно, хорошо, что кто-то не поленился написать для новичков мануал.
правда, эта информация была доступна еще 10 лет назад и, по большому счету, ничего со времен 2.0 и 2.2 не изменилось в работе с символьными устройствами.
все равно, хорошо, что кто-то не поленился написать для новичков мануал.
> Linux Kernel Module или загрузочный модуль ядра
Linux Kernel Module логичнее перевести как модуль ядра линукс, так как слова загрузочный там нет
Linux Kernel Module логичнее перевести как модуль ядра линукс, так как слова загрузочный там нет
На самом деле там Loadable Kernel Module(Загружаемый Модуль Ядра), странно что никто не заметил.
Топик люто плюсую, такие топики должны быть на хабре.
Топик люто плюсую, такие топики должны быть на хабре.
Спасибо Большое! Очень полезно и интересно!
прочитал, отличная статья, ночью попробую! :)
У меня от этой уйни брат умер
> Только что в голову пришла совершенно безумная идея сделать sudo через файл устройства. Т.е. посылаем в /dev/test команду и она выполняется от имени root.
Я когда-то думал об этом, только зашел чуть подальше. Опишу концепт, поэтому просьба сильно не пинать и конструктивно критиковать.
Создаем, например, каталог /dev/perm/, в котором есть несколько типов файлов устройств:
1) системные (root, nobody, syslog, daemon, bin, sys), лежат в /dev/perm/system/;
2) сервисные (устанавливаются вместе с ПО, например, apache, mail, proxy, backup), расположены в /dev/perm/software/);
3) пользовательские (создаются вместе с новыми пользователями, user1, user2 и т.д.), их место — /dev/perm/user/.
При направлении команды в такой файл, он выполняется с соответствующими правами. Более того, на системные или сервисные файлы устройств можно повесить хуки-обработчики событий (об этом чуть ниже).
Рассматриваем классический и «наш» способ:
Во втором случае можно гибко настроить права, ну и вообще должно быть удобнее и безопаснее.
Вот пример с хуком на прокси-сервер:
Во втором случае можно легко настроить права пользователям/группам, которым разрешено администрировать прокси-сервер, к тому же они могут управлять ими, совершенно не задумываясь о «внутренностях».
Про системные хуки даже упоминать не буду: и так понятно, что на них можно повесить (синхронизация фс, включение дополнительного свопа и т.п.).
Вся эта идея может сильно помочь в многопользовательских системах и/или системах с большим количеством групп/виртуальных машин.
Я когда-то думал об этом, только зашел чуть подальше. Опишу концепт, поэтому просьба сильно не пинать и конструктивно критиковать.
Создаем, например, каталог /dev/perm/, в котором есть несколько типов файлов устройств:
1) системные (root, nobody, syslog, daemon, bin, sys), лежат в /dev/perm/system/;
2) сервисные (устанавливаются вместе с ПО, например, apache, mail, proxy, backup), расположены в /dev/perm/software/);
3) пользовательские (создаются вместе с новыми пользователями, user1, user2 и т.д.), их место — /dev/perm/user/.
При направлении команды в такой файл, он выполняется с соответствующими правами. Более того, на системные или сервисные файлы устройств можно повесить хуки-обработчики событий (об этом чуть ниже).
Рассматриваем классический и «наш» способ:
1) sudo su - www-data -c 'mkdir /var/www/test' 2) echo 'mkdir /var/www/test' > /dev/user/software/www-data
Во втором случае можно гибко настроить права, ну и вообще должно быть удобнее и безопаснее.
Вот пример с хуком на прокси-сервер:
1) sudo su - root -c 'service squid restart' 2) echo 'restart' > /dev/user/software/proxy
Во втором случае можно легко настроить права пользователям/группам, которым разрешено администрировать прокси-сервер, к тому же они могут управлять ими, совершенно не задумываясь о «внутренностях».
Про системные хуки даже упоминать не буду: и так понятно, что на них можно повесить (синхронизация фс, включение дополнительного свопа и т.п.).
Вся эта идея может сильно помочь в многопользовательских системах и/или системах с большим количеством групп/виртуальных машин.
>sudo su — www-data -c 'mkdir /var/www/test'
ересь, man 8 sudo
>Во втором случае можно гибко настроить права,
а через sudo нельзя, да? man 5 sudoers, читайте
ересь, man 8 sudo
>Во втором случае можно гибко настроить права,
а через sudo нельзя, да? man 5 sudoers, читайте
> ересь, man 8 sudo
Подробнее?
> а через sudo нельзя, да? man 5 sudoers, читайте
Через sudo нельзя, например, разрешить кому-либо только перезапускать прокси.
Причем неизвестно заранее какой.
Подробнее?
> а через sudo нельзя, да? man 5 sudoers, читайте
Через sudo нельзя, например, разрешить кому-либо только перезапускать прокси.
Причем неизвестно заранее какой.
> Подробнее?
sudo -uwww-data mkdir /var/www/test
> Через sudo нельзя
Что нельзя? Разрешить только перезапускать прокси? Можно.
Не известно какой нельзя, но и в вашем случае система должна откуда-то узнать, что именно ей делать по команде «proxy restart». :)
А идея интересная, только боюсь — не секурно.
sudo -uwww-data mkdir /var/www/test
> Через sudo нельзя
Что нельзя? Разрешить только перезапускать прокси? Можно.
Не известно какой нельзя, но и в вашем случае система должна откуда-то узнать, что именно ей делать по команде «proxy restart». :)
А идея интересная, только боюсь — не секурно.
торт!
а че плюсуем то, копипаста же?
Ну не совсем копипаста уж, статья несколько переработана (и сокращена). Я по этой статье с цитфорума ещё лет 5 назад пытался что-то подобное написать :) Вот намедни в песочнице лежала статья — полная копия главы книги по ассемблеру 1989 года. Вот это копипаста) Её я тоже сразу же узнал (раньше изобилия книг не было, так что читать приходилось всё). И ведь кто-то ещё за неё инвайт получил…
инфа 100%?
Чего только не придумают красноглазые, лишь бы не отдыхать с тёлочками :)
Добавление к UDP3: атомарные операции нужно использовать во всех местах работы с данными. В данном случае и в close().
Защищать нужно не код, а данные :)
Защищать нужно не код, а данные :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем свой драйвер под Linux