Прямой доступ к памяти в Linux
5 ответов
Я думаю, что можно найти много документации о kmalloc + mmap часть. Однако я не уверен, что Вы можете kmalloc такая память непрерывным способом, и всегда иметь его в том же месте. Несомненно, если все всегда - то же, тогда Вы могли бы получить базовый адрес. Однако каждый раз, когда Вы изменяете код ядра, Вы получите различный адрес, таким образом, я не пошел бы с kmalloc решением.
я думаю, что необходимо зарезервировать некоторую память во время начальной загрузки, т.е. зарезервировать некоторую физическую память так, чтобы был, не затронут ядром. Тогда Вы можете ioremap эта память, которая даст Вам виртуальный адрес ядра, и затем Вы можете mmap это и писать хороший драйвер устройства.
Это забирает нас к драйверы устройств Linux в формате PDF. Взгляните на главу 15, она описывает эту технику на Редактировании страницы 443
: ioremap и mmap. Я думаю, что это могло бы быть легче отладить выполнение вещей в два, ступите: сначала разберитесь в ioremap и протестируйте его с помощью эксплуатации устройства посимвольного ввода-вывода, т.е. чтения-записи. Как только Вы знаете, что у Вас может безопасно быть доступ к целому ioremapped чтению использования памяти / запись, тогда Вы пробуете к mmap целый диапазон ioremapped.
И если Вы входите в проблему, может быть сообщение другой вопрос об отображении
Редактирование: remap_pfn_range ioremap возвращает virtual_adress, который необходимо преобразовать в pfn для remap_pfn_ranges. Теперь, я не понимаю точно, каков pfn (Число Страничного блока), но я думаю, что можно получить один вызов
virt_to_phys(pt) >> PAGE_SHIFT
, Это, вероятно, не Правильный Путь (TM), чтобы сделать это, но необходимо попробовать его
, необходимо также проверить, что FOO_MEM_OFFSET является физическим адресом блока RAM. Т.е. прежде чем что-либо происходит с mmu, Ваша память доступна в 0 в карте распределения памяти Вашего процессора.
Извините, что ответил, но не совсем ответить, я заметил, что Вы уже отредактировали вопрос. Обратите внимание на то, что ТАК не уведомляет нас, когда Вы редактируете вопрос. Я даю универсальный ответ здесь, когда Вы обновляете вопрос, оставьте комментарий, тогда я отредактирую свой ответ.
Да, Вы испытываете необходимость для записи модуля. То, к чему это сводится, является использованием kmalloc() (выделение региона в пространстве ядра) или vmalloc() (выделение региона в пространстве пользователя).
Представление предшествующего легко, представление последнего может быть болью сзади с видом интерфейса, который Вы описываете по мере необходимости. Вы отметили, что 1,5 МБ являются грубой оценкой того, сколько на самом деле необходимо зарезервировать, который является железный одетый? Т.е. Вы - удобное взятие это от пространства ядра? Можно ли соответственно иметь дело с ENOMEM или EIO от пространства пользователя (или даже дисковый сон)? IOW, что входит в этот регион?
кроме того, будет параллелизмом проблема с этим? Если так, будут Вами использующий futex? Если ответ любому - 'да' (особенно последний), ее вероятное, что необходимо будет стиснуть зубы и пойти с vmalloc() (или гниль ядра риска из). Кроме того, если Вы даже ДУМАЕТЕ о ioctl() интерфейс к символьному устройству (специально для некоторой специальной идеи блокировки), Вы действительно хотите пойти с vmalloc().
кроме того, Вы читали это ? Плюс мы даже не затрагиваем то, какой grsec / selinux собирается думать об этом (если используемый).
/dev/mem хорошо для простого регистра, посмотрел и вводит по абсолютному адресу, но как только Вы пересекаетесь в прерывания и территорию DMA, действительно необходимо записать драйвер привилегированного режима. Что Вы сделали для своих предыдущих Ose управления памятью меньше, просто не прививает хорошо к Общей цели ОС как Linux.
Вы уже думали о проблеме распределения буферов DMA. Теперь, думайте о "DMA сделанное" прерывание от своего устройства. Как Вы собираетесь установить Процедуру обработки прерывания?
Кроме того,/dev/mem обычно блокируется для некорневых пользователей, таким образом, это не очень практично для общего использования. Несомненно, Вы могли chmod это, но тогда Вы открыли большую дыру в системе безопасности в системе.
, При попытке сохранить кодовую базу драйвера подобной между Ose, необходимо рассмотреть рефакторинг ее в отдельного пользователя & слои привилегированного режима с подобным IOCTL интерфейсным промежутком. Если Вы пишете часть непривилегированного режима как универсальная библиотека кода C, это должно быть легко к порту между Linux и другими Ose. Определенная для ОС часть является кодом привилегированного режима. (Мы используем этот вид подхода для наших драйверов.)
кажется, что Вы уже пришли к заключению, что пора записать драйвер ядра, таким образом, Вы на правильном пути. Единственный совет, который я могу добавить, состоит в том, чтобы прочитать эти полные книги.
(Имеют в виду, что эти книги приблизительно 2005, таким образом, информация немного датирована.)
Я не безусловно никакой эксперт по этим вопросам, таким образом, это будет вопросом Вам, а не ответу. Есть ли какая-либо причина, Вы не можете только сделать маленький раздел диска поршня и использовать его только для Вашего приложения? Разве это не дало бы Вам гарантируемый доступ к тому же блоку памяти? Я не уверен в были бы любые проблемы производительности ввода-вывода или дополнительные издержки, связанные с выполнением этого. Это также предполагает, что можно сказать ядру делить определенный диапазон адресов в памяти, не уверенной, если это возможно.
я приношу извинения за newb вопрос, но я нашел Ваш вопрос интересным, и любопытен, если диск поршня мог бы использоваться таким способом.
Have you looked at the 'memmap' kernel parameter? On i386 and X64_64, you can use the memmap parameter to define how the kernel will hand very specific blocks of memory (see the Linux kernel parameter documentation). In your case, you'd want to mark memory as 'reserved' so that Linux doesn't touch it at all. Then you can write your code to use that absolute address and size (woe be unto you if you step outside that space).