Comments 33
UFO just landed and posted this here
Поправил кавычки, спасибо.
Код компилируется потому что в языке С — это вполне допустимая конструкция, называется designated-initializer
Код компилируется потому что в языке С — это вполне допустимая конструкция, называется designated-initializer
Очень познавательно, спасибо!
А что это за антенна такая на видео?
А что это за антенна такая на видео?
Это телескоп гамма излучения.
24 зеркала, фокусирующих свет на 4 приемные корзины. В каждой корзине — 37 ФЭУ (фотоэлектронный умножитель).
Телескоп улавливает Черенковские вспышки от влетающих в атмосферу гамма-частиц.
24 зеркала, фокусирующих свет на 4 приемные корзины. В каждой корзине — 37 ФЭУ (фотоэлектронный умножитель).
Телескоп улавливает Черенковские вспышки от влетающих в атмосферу гамма-частиц.
У этих телескопов ГТ-48 интересная история с опорно-поворотными устройствами kik-sssr.ru/41E_Simeiz.htm
В функции «lirdev_read» присутствует уязвимость позволяющая читать стэк ядра. Всё дело в том, что в вызове функции «copy_to_user» параметр отвечающий за размер копируемых данных контролирует пользователь. По хорошему надо заменить на контрукцию:
dt_size = min(4,count);
copy_to_user(buf, &data, dt_size);
А так да, статья очень полезная) Спасибо)
Возможно я пропустил, но под какое ядро писался код? Это очень важная информация. А так, на мой взгляд блестящее решение. Уважаю!
Статья шикарная!
Как отреагировал производитель о написанном драйвере?
Как отреагировал производитель о написанном драйвере?
Подобного материала в рунете не так уж и много, так что спасибо, статья отличная!
А когда ядро обновляется в системе, ручками пересобираете драйвер? Недавно узнал зачем надо dkms в системе)
>>Существует несколько путей общения вышестоящего ПО с нашим драйвером. Одним из самых старых, простых и популярных способов является символьное устройство
расскажите плиз о др способах общения ПО из юзер спейса с драйверами
расскажите плиз о др способах общения ПО из юзер спейса с драйверами
Об одном из таких, других, способов я уже писал довольно давно. Это netlink.
Еще один способ — через виртуальные файловые системы (/proc, /sys). В частности именно таким образом различные утилиты получают от ядра информацию таблице маршрутизации, запущенных процессах, обращениях к диску и т.п.
Другой механизм — системные вызовы, через него с ядром общается, например, стандартная библиотека С.
Вообще наверное стоит написать отдельную статью, о способах общения с модулем ядра и подробнее про netlink рассказать, интересная штука.
Еще один способ — через виртуальные файловые системы (/proc, /sys). В частности именно таким образом различные утилиты получают от ядра информацию таблице маршрутизации, запущенных процессах, обращениях к диску и т.п.
Другой механизм — системные вызовы, через него с ядром общается, например, стандартная библиотека С.
Вообще наверное стоит написать отдельную статью, о способах общения с модулем ядра и подробнее про netlink рассказать, интересная штука.
Блестящая статья!
Большое спасибо! Литература по написанию драйверов вроде бы есть, и неплохая, но там, как правило, рассматриваются простейшие абстрактные примеры блочных устройств или что-то подобное. Думаю, что эта статья — хорошее дополнение.
Вот вам неплохой цикл, помимо книжки Linux Device Drivers: https://www.ibm.com/developerworks/ru/library/l-linux_kernel_01/index.html, мне очень помог въехать в PCI подсистему плюс разобраться с SPI я ядре.
Подскажите, пожалуйста, а какова вероятность «подвесить ядро», если в процедуре wait_for_transaction_finish аппаратура так и не выставит бит готовности, или, скажем, сделает это через пол-минуты? Я не очень разбираюсь в архитектуре ядра, мне интересно, в каком потоке работает этот код, и что может оказаться отложенным из-за такого ожидания? Просто чтение из аппаратуры обычно делается на основе прерываний, которые и сигнализируют в таких случаях, что данные готовы.
Т.к. вся процедура чтения по факту вызывается пользовательским приложением, то и выполняется этот код в контексте читающего потока приложения.
К самому ядру это отношения не имеет.
Соответственно если вдруг где-то застрянет железо — то в ожидании застрянет лишь пользовательское приложение, в методе read() на символьном устройстве. Это не подвесит остальную систему с прочими приложениями и процедура вполне подлежит завершению.
Не выставление бита может означать какой-то серъезный сбой с платой, и очевидно работать с ней дальше не выйдет. В случае же отвала лишь датчика — пауза все равно будет выставлена и из памяти будет прочитано нулевое значение.
Конечно если есть возможность — лучше всего использовать прерывания, но в данном случае они недоступны.
К самому ядру это отношения не имеет.
Соответственно если вдруг где-то застрянет железо — то в ожидании застрянет лишь пользовательское приложение, в методе read() на символьном устройстве. Это не подвесит остальную систему с прочими приложениями и процедура вполне подлежит завершению.
Не выставление бита может означать какой-то серъезный сбой с платой, и очевидно работать с ней дальше не выйдет. В случае же отвала лишь датчика — пауза все равно будет выставлена и из памяти будет прочитано нулевое значение.
Конечно если есть возможность — лучше всего использовать прерывания, но в данном случае они недоступны.
Sign up to leave a comment.
Разработка драйвера PCI устройства под Linux