Доступ к устройству платформы из пользовательского пространства

С общей точки зрения, я пытаюсь понять, как получить доступ к платформенному устройству из пользовательского пространства. Чтобы быть более конкретным, у меня есть контроллер EMIF и SoC, который я добавил в свое дерево устройств, и я считаю, что он правильно привязан к предварительно написанному драйверу устройства платформы EMIF. Теперь я пытаюсь выяснить, как я могу получить доступ к этому устройству EMIF из приложения пользовательского пространства. Я столкнулся с парой разных тем, которые, кажется, имеют какое-то отношение к этой проблеме, но я не могу понять, как они связаны.

1) Как я читал, кажется, что большая часть операций ввода-вывода выполняется с использованием узлов устройств, созданных mknod(), нужно ли мне создавать узел устройства, чтобы получить доступ к этому устройству?

2) Я прочитал пару тем, в которых говорится о написании модуля ядра (символ?, блок?), который может взаимодействовать как с пользовательским пространством, так и с драйвером устройства платформы, и использовать его в качестве посредника.

3) Я прочитал о возможности использования mmap() для сопоставления памяти моего устройства платформы с моим виртуальным пространством памяти. Это возможно?

4) Кажется, что когда создается экземпляр драйвера EMIF, он вызывает функцию probe(). Какие функции пользовательское приложение будет вызывать в драйвере?


linux-kernel embedded-linux driver linux-device-driver system-on-chip
person whh4000    schedule 08.04.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Не совсем понятно, что вам нужно делать (и я должен предостеречь, что у меня нет опыта работы с EMIF или с «платформенными устройствами»), но вот некоторый обзор, который поможет вам начать работу:

  1. Да, обычный способ предоставления доступа к устройству — через узел устройства. Обычно этот доступ предоставляется драйвером символьного устройства, если нет более конкретного способа его предоставления. В большинстве случаев, если приложение общается с вашим драйвером «напрямую», это символьное устройство. Большинство других типов устройств используются для взаимодействия с другими подсистемами ядра: например, блочное устройство обычно используется для обеспечения доступа из драйвера файловой системы (скажем) к базовому диску; сетевой драйвер обеспечивает доступ к сети из стека TCP/IP в ядре и т. д.

    Существует несколько методов символьного устройства или точек входа, которые могут поддерживаться вашим драйвером, но наиболее распространенными являются "чтение" (т.е. если программа пользовательского пространства открывает ваше устройство и выполняет чтение(2) с него), "запись" (аналогично записи(2)) и "ioctl" (часто используется для конфигурационных/административных задач, которые естественным образом не относятся ни к чтению, ни к записи). Обратите внимание, что mknod(2) создает только пользовательскую сторону устройства. В ядре должен быть соответствующий драйвер устройства («старший номер устройства», заданный в вызове mknod, связывает узел пользовательского пространства с драйвером).

    Для фактического создания узла устройства в файловой системе это можно автоматизировать (т. е. узел автоматически появится в /dev), если вы вызываете правильные функции ядра при настройке устройства. Существует специальный демон, который получает уведомления от ядра и отвечает, выполняя системный вызов mknod(2).

  2. Модуль ядра — это просто динамически загружаемый способ создания драйвера или другого расширения ядра. Он может создать персонажа, блок или сетевое устройство (и др.), но также может и статически связанный модуль. Существуют некоторые различия в возможностях, главным образом потому, что не все функции ядра, которые вы, возможно, захотите использовать, «экспортируются» (т. е. видны) в динамически загружаемые модули.

  3. Возможна поддержка отображения памяти устройства в пространство виртуальной памяти пользователя. Это будет реализовано с помощью еще одной точки входа драйвера (mmap). См. struct file_operations для всех точек входа, которые может поддерживать драйвер char.

  4. Это в значительной степени зависит от вас: это зависит от того, что приложение должно уметь делать. В ядре есть много драйверов, которые не предоставляют прямых функций пользовательскому пространству, а только другому коду ядра. Что касается "зонда", то существует множество функций зонда, определенных в различных интерфейсах. В большинстве случаев они вызываются ядром (или, возможно, «драйвером «класса» более высокого уровня»), чтобы позволить конкретному драйверу обнаруживать, идентифицировать и «заявлять» отдельные устройства. Они (зондовые функции) обычно не имеют прямого отношения к предоставлению доступа из пользовательского пространства, но я вполне могу что-то упустить в конкретном интерфейсе.

person Gil Hamilton    schedule 08.04.2014
comment
Я предполагаю, что мне интересно, исходя из мира встроенных микроконтроллеров, как мне получить доступ к этому аппаратному обеспечению, которое я обычно (без операционной системы) просто ссылался бы на регистры и читал и писал в них? - person whh4000; 09.04.2014
comment
Если это просто случайное изменение настроек, вероятно, лучше всего подойдет символьное устройство с поддержкой ioctl. Если это то, с чем вам нужно постоянно возиться во время выполнения, и если производительность при этом имеет решающее значение, то может иметь смысл использовать mmap. - person Gil Hamilton; 09.04.2014
comment
...из мира встроенных микроконтроллеров -- использование uC не имеет к этому никакого отношения. Это отсутствие структуры SW. Вы можете организовать FW в слои и реализовать инкапсуляцию ресурсов. Мне приходилось работать с Z80 и 8051 FW, которые не придерживались концепции структуры ПО. - person sawdust; 11.04.2014
comment
Модуль ядра — это просто динамически загружаемый... -- Не все модули ядра загружаемы. Модули могут быть статически связаны с образом ядра. Некоторые модули могут даже не иметь возможности загрузки (например, драйвер (модуль) последовательного порта tty, используемый системной консолью, должен быть встроенным). - person sawdust; 11.04.2014

arrow_upward
0
arrow_downward

Для доступа к устройству необходимо создать узел устройства.

Функция probe вызывается, когда драйвер находит соответствующее устройство.

Для получения информации об API устройств платформы могут быть полезны следующие статьи.

API устройства платформы Устройства платформы и деревья устройств

person Sagar Jain    schedule 10.04.2014