а у тебя случаем нет списка книг, по которым ты обучался встроенным системам да и работе с микропроцессорами
в GPIO пин прокинул пятерку с 7 по 9 биты, т.е. тем самым включил прерывание при высоком уровне
Может прерывания нужно как-то явно включать процессорной командой, не знаешь?
PS.EXCM и установкой PS.INTLEVEL в значение ниже уровня прерываний которые нужно разрешить и 2) установкой битов в регистре INTENABLE соответствующих конкретным IRQ которые нужно разрешить.
ты утверждаешь что mmap при мапинге /dev/mem будет напрямую писать в физическую память ??
mmap не будет никуда писать. Но mmap может отобразить любую область физической памяти в адресное пространство процесса для прямого доступа.тогда получается любой пользователь может получить доступ к любому участку физической памяти без каких-либо проверок, только за'mmap'ив /dev/mem в своей проге ??
/dev/mem.
mmap в mem_fops, mem_fops указаны как fops в массиве devlist для устройства с минорным кодом DEVMEM_MINOR, этот массив обрабатывается здесь, где регистрируются устройства с мажорным кодом MEM_MAJOR. Устройство с кодом 1, 1 -- это /dev/mem и есть, как можно увидеть здесь
…но это совсем не в тему
…в контексте вопроса сие не имеет значения.
код, реализующий mmap под /dev/mem, не приводил :)
это потребует наличие в хуке кода обработки доступов пользователя к /dev/mem.
open, которым файл открывают.сильно сомневаюсь что такой хук будет внедрен, смысл в нем ??
mmap для /dev/mem, в чём ты конкретно сомневаешься, я не понял?
в каком месте бредовость ??
mmap отлавливает это изменение…
…и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь
выявляет подстрочку /dev
/dev/mem работает только пока он в /dev, а если его перенести в какое-нибудь другое место, то он работать перестанет?и направляет его в драйвер udev ответственный за этот путь
не все знаю, чего в этом криповатого ??
Цепочку действий для записи значения в память с помощью спец.файла /dev/mem я привел чуть выше.
Приведи свою.
Я сильно сомневаюсь что в функции mmap есть хук под файл /dev/mem
/dev/mem конечно нет. Есть поле mmap в структуре file_operations, позволяющее любой файловой системе или драйверу предоставить свою реализацию mmap для файлов которые они обслуживают. Опять же, любая книжка по внутренностям ядра об этом рассказывает.
неа, ваапче не так :)
согласен. этих подробностей не знаю.
запись значения в память, посредством /dev/mem, проходит кучу прослоек
mmap отображает фал на произвольную память, котрую ему выдал менджер памяти. ты записываешь в эту область, mmap отлавливает это изменение и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь, выявляет подстрочку /dev и направляет его в драйвер udev ответственный за этот путь. udev перенаправляет запрос в драйвер, ответственный за /dev/mem, и только он разбирает файловый запрос и пишет напрямую в указанный адрес физической памяти.
/dev/mem и передаёшь его fd в системный вызов mmap, в ядре вызывается функция mmap_mem зарегистрированная здесь. Эта функция, как можно увидеть здесь, вызывает remap_pfn_range для выделенного участка виртуальной памяти, а в качестве параметра pfn, определяющего номер страницы физической памяти, как написано здесь, передаёт vma->vm_pgoff, т.е. смещение, переданное mmap, но выраженное в страницах. Т.е. не "произвольную память, котрую ему выдал менджер памяти", а вполне конкретную физическую память, которую ты попросил в вызове mmap.
обычно -O3 для отладки с макс. кол-вом символов
-O3 -- это максимальная оптимизация. Максимальная отладочная информация -- -g3. Уровень отдладочной информации выбранной ключом -g не влияет на сгенерированный код.
Да, так можно сделать.
Вопрос непонятен. В чём проблема?