Страницы: 1 | (1)
Т.е. твой драйвер создает страницу памяти, которую шарит внутрь виртуального адресного пространства твоего userspace процесса. Ну и дальше перегоняет данные из устройства в эту страницу, а userspace процесс - читает из нее (например, в цикле).
А если доступ к устройству - простой memory-mapped, API устройства простое, и устройство отдает данные быстро, то можно смаппить прямо адресное пространство устройства внутрь userspace процесса.
Ну или вообще, реализовать код userspace процесса in-kernel.
Вообще, тебя какая модель общения интересует? Чтобы userspace процесс on-demand дергал какую-то функцию, и она отдавала с минимальным latency текущее значение из устройства? Или тебе нужно последовательность значений из устройства вытаскивать (не потеряв промежуточные значения)?
1. Драйвер при инициализации выделяет страницу памяти (kmalloc). Запоминает ее адрес.
2. Драйвер постоянно перегоняет данные из устройства в эту страницу
3. Драйвер реализует ioctl, результат которого - физический адрес этой странички
4. Процесс при инициализации дергает этот ioctl, тем самым знает, откуда эти данные забирать
5. Процесс отображает эту страницу в свое виртуальное пространство (mmap на /dev/mem по полученному выше адресу).
6. Теперь процесс может считывать в цикле данные из отображенной страницы
Замечание #1. Использование /dev/mem требует соответствующих прав и, вообще говоря, несколько криво. Наверняка, есть более красивый способ.
Замечание #2. Если данные не влезают в машинное слово, то можно огрести проблем с атомарностью. Например, считывание 128-битного значения на 64-битной архитектуре требует два 64-битных mov, тем самым ты можешь получить левую часть от считывания N_i, а правую - от считывания N_j.
Традиционная книжка по драйверам: http://www.makelinux.net/ldd3/
прошу прощения, прерывание по неотложным причинам
в которую драйвер записал данные хуй знает когда. Едро вместо этого сначала
прошу прощения, прерывание по неотложным причинам
подгружает локальную и глобальную таблицы дескрипторов чтобы удостовериться, что сраный юзерспейс
прошу прощения, прерывание по неотложным причинам
имеет право читать эти
прошу прощения, прерывание по неотложным причинам
данные, когда ядро убедилось что
прошу прощения, прерывание по неотложным причинам
твой процесс имеет право доступа к
прошу прощения, прерывание по неотложным причинам
данной области памяти, оно начинает долго и томи
прошу прощения, прерывание по неотложным причинам
тельно тянуть эти четыре килоба
прошу прощения, прерывание по неотложным причинам
йта из RAM потому, что друг
прошу прощения, прерывание по неотложным причинам
ие процессы уже вытеснили страницу из кеш-лайна.
Вот что тут можно гарантировать для рил-тайма кроме 100% потребления одного ядра CPU?
Как происходит забирание данных из устройства: чтение из памяти (mov) или чтение из порта (inb/inw)? Сколько времени обходится одно чтение?
Просто мне кажется, что в твоем случае самый простой способ будет и самым быстрым:
1) userspace дергает некий ioctl
2) драйвер при получении ioctl опрашивает устройство и возвращает значение как результат ioctl
Если чтение из устройства использует только mov, то можно заморочиться и код драйвера перенести в сам userspace процесс (общение в память через /dev/mem). Будет экономия на syscall.
P.S. Ну и это, что-то у тебя слишком часто прерывания идут. Может, их обработку на другие ядра перевесить?
В ответ на:
Вот что тут можно гарантировать для рил-тайма кроме 100% потребления одного ядра CPU?
Линукс не является системой RTOS по определению, твоя задача наверняка решается куда проще чем ты сейчас загоняешь.
Создаешь FIFO и пихаешь в него твои данные.