http://rulinux.net/ http://rulinux.net/ http://rulinux.net/rss_icon.png https://rulinux.net/message.php?newsid=42385&page=1#215732 https://rulinux.net/message.php?newsid=42385&page=1#215732 Sat, 09 Apr 2016 09:47:26 +0300 Вышеуказанное решение я написал из расчета, что данные уже в ядре, и тебе осталось только сделать "Вывод быстроменяющихся данных из ядра в пользовательское пространство". Про busyloop в ядре я ничего не писал, только в userspace. :)

Как происходит забирание данных из устройства: чтение из памяти (mov) или чтение из порта (inb/inw)? Сколько времени обходится одно чтение?

Просто мне кажется, что в твоем случае самый простой способ будет и самым быстрым:

1) userspace дергает некий ioctl

2) драйвер при получении ioctl опрашивает устройство и возвращает значение как результат ioctl

Если чтение из устройства использует только mov, то можно заморочиться и код драйвера перенести в сам userspace процесс (общение в память через /dev/mem). Будет экономия на syscall.

P.S. Ну и это, что-то у тебя слишком часто прерывания идут. Может, их обработку на другие ядра перевесить?

P.P.S. Тебе что важнее: получить как можно более свежие данные или как можно меньше блокировать процесс? Одновременно и то, и другое не получится.

]]> https://rulinux.net/message.php?newsid=42385&page=1#215718 https://rulinux.net/message.php?newsid=42385&page=1#215718 Fri, 08 Apr 2016 20:56:36 +0300 Я вот тоже не понял.

]]> https://rulinux.net/message.php?newsid=42385&page=1#215715 https://rulinux.net/message.php?newsid=42385&page=1#215715 Fri, 08 Apr 2016 20:47:04 +0300 А накуй ему тогда линукс?

]]> https://rulinux.net/message.php?newsid=42385&page=1#215713 https://rulinux.net/message.php?newsid=42385&page=1#215713 Fri, 08 Apr 2016 20:42:48 +0300 Кого волнует вывод от сенсоров материнской платы, когда человек реально задрачивается по счётчику времени в процессоре?

]]> https://rulinux.net/message.php?newsid=42385&page=1#215708 https://rulinux.net/message.php?newsid=42385&page=1#215708 Fri, 08 Apr 2016 20:18:43 +0300 Очень интересно, ну а что ты <прошу прощения> предлагаешь? lol

ТС, посмотри как реализуется вывод от сенсоров материнской платы, возможно тебе этого хватит.

]]> https://rulinux.net/message.php?newsid=42385&page=1#215703 https://rulinux.net/message.php?newsid=42385&page=1#215703 Fri, 08 Apr 2016 19:14:01 +0300 Ты больной на всю голову. Прикинь, тебе нужно сообщить 64 бита в юзерспейс. При чём о состоянии регистра, значение которого меняется чаще чем исполняются машинные команды. Ты делаешь драйвер, который тратит 100% CPU на копирование этого регистра в какую-то там память, с потерями. Потом юзерский процесс пытается достучаться до этих восьми байт - обращается к 4196-байтной странице памяти, <прошу прощения, прерывание по неотложным причинам> в которую драйвер записал данные хуй знает когда. Едро вместо этого сначала <прошу прощения, прерывание по неотложным причинам> подгружает локальную и глобальную таблицы дескрипторов чтобы удостовериться, что твой сраный юзерспейс <прошу прощения, прерывание по неотложным причинам> имеет право читать эти <прошу прощения, прерывание по неотложным причинам> данные, когда ядро убедилось что <прошу прощения, прерывание по неотложным причинам> твой процесс имеет право доступа к <прошу прощения, прерывание по неотложным причинам> данной области памяти, оно начинает долго и томи<прошу прощения, прерывание по неотложным причинам>тельно тянуть эти четыре килоба<прошу прощения, прерывание по неотложным причинам>йта из RAM потому, что друг<прошу прощения, прерывание по неотложным причинам>ие процессы уже вытеснили страницу из кеш-лайна.

Вот что тут можно гарантировать для рил-тайма кроме 100% потребления одного ядра CPU?

]]> https://rulinux.net/message.php?newsid=42385&page=1#215700 https://rulinux.net/message.php?newsid=42385&page=1#215700 Fri, 08 Apr 2016 17:32:21 +0300 Как-то так:

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/

]]> https://rulinux.net/message.php?newsid=42385&page=1#215699 https://rulinux.net/message.php?newsid=42385&page=1#215699 Fri, 08 Apr 2016 17:30:31 +0300 Ну, традиционно самый быстрый способ — это через отображение памяти. Системные вызовы, связанные со временем, делаются именно так.

Т.е. твой драйвер создает страницу памяти, которую шарит внутрь виртуального адресного пространства твоего userspace процесса. Ну и дальше перегоняет данные из устройства в эту страницу, а userspace процесс — читает из нее (например, в цикле).

А если доступ к устройству — простой memory-mapped, API устройства простое, и устройство отдает данные быстро, то можно смаппить прямо адресное пространство устройства внутрь userspace процесса.

Ну или вообще, реализовать код userspace процесса in-kernel.

Вообще, тебя какая модель общения интересует? Чтобы userspace процесс on-demand дергал какую-то функцию, и она отдавала с минимальным latency текущее значение из устройства? Или тебе нужно последовательность значений из устройства вытаскивать (не потеряв промежуточные значения)?

]]> https://rulinux.net/message.php?newsid=42385&page=1#214672 https://rulinux.net/message.php?newsid=42385&page=1#214672 Mon, 01 Feb 2016 15:29:44 +0300 Спасибо за совет! А приоритетами задержки будет не побороть? Или скажем RT патчем?
Еще очень хочу скомпилить ядро с кое-какими параметрами для целей отладки (а именно CONFIG_PROC_KCORE и CONFIG_KGDB_SERIAL_CONSOLE), но что-то не могу их найти в menuconfig'е... Не подскажите, плз, где их искать?

]]> https://rulinux.net/message.php?newsid=42385&page=1#214619 https://rulinux.net/message.php?newsid=42385&page=1#214619 Thu, 28 Jan 2016 16:58:01 +0300 Типа того. Если речь о быстроменяющихся счётчиках, то наверняка контроллер нужен а не многозадачная система с непредсказуемыми задержками.

]]> https://rulinux.net/message.php?newsid=42385&page=1#214618 https://rulinux.net/message.php?newsid=42385&page=1#214618 Thu, 28 Jan 2016 16:36:07 +0300 > проблему твою наверняка надо решать аппаратно.
Ардуину на ком-порт?

]]> https://rulinux.net/message.php?newsid=42385&page=1#214616 https://rulinux.net/message.php?newsid=42385&page=1#214616 Thu, 28 Jan 2016 16:32:04 +0300 По-yahoo-й на тему "создание драйверов linux" - там и хабровские хелловорлды найдутся и книжки соответствующие. Но в целом проблему твою наверняка надо решать аппаратно.

]]> https://rulinux.net/message.php?newsid=42385&page=1#214615 https://rulinux.net/message.php?newsid=42385&page=1#214615 Thu, 28 Jan 2016 16:12:11 +0300 Здравствуйте! Очень нужен совет программистов-ядерщиков и всех кто имел дела с написанием/модификацией драйверов/модулей. Есть драйвер, который нужно малость допилить. В общем нужно в этом драйвере как-то считывать значения определенных регистров и передавать их в юзерспейс, причем значения эти быстроменяются (счетный регистр таймера). Сами функции считывания написаны, остается только придумать каким способом отслеживать эти значения из пользовательского пространства. В процессе поиска выяснилось, что можно использовать procfs, sysfs, Netlink, ioctl и наверняка много чего еще. В принципе из драйвера проброшены атрибуты в sysfs, так что можно сделать аналогичным образом, но я не знаю насколько быстро будет происходить обновление значения атрибута (файла в sysfs). Плюс мне не совсем до конца понятна вся концепция модели устройств. Если у кого есть хорошая-годная литература по этому всему, то я обязательно RTFM.

]]>