Перейти к содержанию
    

Вопросы по написанию драйвера под Linux

Добрый день.

 

Начал переходить с Bare metal на Linux.

Пытаюсь разобраться как написать простенький драйвер для моей ip core. Пока это просто 8 лампочек.

Борда: zedboard.

 

Сейчас читаю литературу, т.к. до этого не было опыта написания драйверов.

 

1) Не рекомендуется писать драйвер под файловую систему /dev. Раньше конечно так делали. Сейчас, якобы актуально писать под файловую систему /proc или /sys.

Верно ли это? Хочется сразу научиться праивльным вещам. :maniac: Т.е. может при написании драйвера под какую-нибудь фс скрываются ккаие-то подводные камни. И есть резон писать под другую фс.

 

2) Почитал https://linuxseekernel.blogspot.com/2014/05...-practical.html и, честно говоря, так и не понял какое различие между:

Platform Driver

Platform Device

Т.е. это два независимых варианта? Или есть определенные случаи когда стоит что-то конкретное из этого использовать?

 

3) Как я понял. Написание дравера состоит из двух больших шагов.

а) Создать виртуальный файл в файловой системе. Чтобы в него можно было писать/читать и т.д.

б) Связать этот виртуальный файл с физическим устройством.

Верно?

 

 

4) Пока нашел такой код. Все нормально работает. myled.txt

Как можно реализовать чтение и запись в регистры с определенным сдвигом? Действовать через base_addr (он определен в коде)?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) Когда разбирался с драйверами(полтора года назад) не видел рекомендаций об отказе от файлов в /dev, были рекомендации не использовать функцию ioctl для управления настройками устройства/драйвера, в пользу управления настойками через файлы в /sys

 

2) Device - это устройство, в вашем случае "лампочки", Driver - это программа управляющая этим устройством, которую вы разрабатываете. Platform - значит, что усройство встоенное, т.е. всегда подключено.

Т.е. это две разные сущности - встроенное устройство(железо) и драйвер для встроенного устойства(программа).

 

3) Я бы сказал написание драйвера это написание функций-обработчиков чтения/записи и т.д файлов. Создание файла устойства и связь его с устойством(драйвером) сейсас дело пару сток, в вашем случае это делает функция proc_create().

 

4) base_addr - связан с регистрами устойства "лампочки", если у этого устойства несколько подряд идущих регистров(и это описано в конфигурационных файлах), то да, к ним можно обращаться смещаясь относитльно base_addr.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо!

 

От себя только добавлю, что тема про Platform device и Platform driver хорошо раскрыта здесь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Случайно увидел ваш вопрос. Пишите про Линукс в теме Линукс.

 

1) Не рекомендуется писать драйвер под файловую систему /dev. Раньше конечно так делали. Сейчас, якобы актуально писать под файловую систему /proc или /sys.

Верно ли это? Хочется сразу научиться праивльным вещам. maniac.gif Т.е. может при написании драйвера под какую-нибудь фс скрываются ккаие-то подводные камни. И есть резон писать под другую фс.

 

В этом вопросе каша.

На самом деле все происходит таким образом:

Вы регистрируете драйвер, ядро записывает информацию о нем в соответствующие структуры и драйвер появляется в /sys/.

В дереве устройств вы описываете устройство для этого драйвера (в /sys появятся записи об устройстве) и если они (драйвер и устройство) соответствуют друг другу, то вызовется функция драйвера probe. Если probe не вернет ошибку, то устройство встало и подключилось к драйверу. Если у вас написано правило для этого устройства в правилах udev, то в /dev появится псевдофайл для доступа к вашему устройству. Если нет, то его можно создать при помощи команды mknod.

 

platform device:

Вы наверняка за обилием информации не заметили важнейшего момента, что драйвер и устройство должны СООТВЕТСТВОВАТЬ друг другу. На самом деле драйверы (о блоковых драйверах мы вообще не говорим) подразделяются на несколько групп. Список этих групп вы найдете в разделе шин: /sys/bus/ Оказалось, что есть такая группа, которую ни к одной шине отнести нельзя. Ее назвали platform.

 

Внутри каждой группы свои правила по которым проверяется соответствие драйвера и устройства. Для PCI и USB это Vendor ID и Product ID, для platform это просто текстовое имя. Это должно совпасть в драйвере и устройстве.

 

На самом деле есть еще нюансы, но в целом картина выглядит таким образом.

 

Спасибо!

 

От себя только добавлю, что тема про Platform device и Platform driver хорошо раскрыта здесь.

 

В этом тексте все описано для ядер до 2.6.Х включительно. С 3.Х.Х вместо структуры устройства в тексте программы начали описывать устройства в дереве устройств.

 

 

Можно на все положить и сделать нестандартно, но так профессионалы не будут делать. Сделать доступ к программе (не могу назвать это драйвером) через интерфейс /proc. Но так сделать легко. Как это делать подробно изложено здесь:

https://www.iitg.ac.in/asahu/cs421/books/LKM2.6.pdf

 

Это навскидку нашел. есть и более свежие версии этого документа.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1.

В этом вопросе каша.

Почитал методу на ibm. Давайте напишем модуль под /dev; /sys; /proc. Этот модуль вы можете допилить до драйвера. В таком духе.

Поэтому то, что вы написали далее я и не знал.

 

2.

С 3.Х.Х вместо структуры устройства в тексте программы начали описывать устройства в дереве устройств.

Да, сейчас сам описыал в device tree устройство и поэтому не доходило про platform device. Зачем описывать структуру устройства в platform device, если еcть device tree.

 

3.

На самом деле драйверы (о блоковых драйверах мы вообще не говорим) подразделяются на несколько групп. Список этих групп вы найдете в разделе шин: /sys/bus/ Оказалось, что есть такая группа, которую ни к одной шине отнести нельзя. Ее назвали platform.

 

Platform devices сами по себе не поддаются обнаружению. Т.е. устройство не может сказать "Эй! Я присутствую!" программному обеспечению. Что делать?

Для это была введена виртуальная шина (platform bus). С одной стороны устройства подключаются к такой шине, а с другой - к шине присоединяются драйвера, которые запрашивают устройства с необходимым именем.

 

Т.е. за это как раз и отвечают эти строки:

// Из device tree
static const struct of_device_id myled_of_match[] = {
    {.compatible = "xlnx,myled-1.0"},
        {},
};

static struct platform_driver myled_driver = {
    .driver = {
            .name = DRIVER_NAME,
             .owner = THIS_MODULE,
                .of_match_table = myled_of_match},
        .probe = myled_probe,                                  // Обязательно
        .remove = myled_remove,
        .shutdown = myled_shutdown
};

 

Но для PCI и USB там другая картина. Как вы и написали.

 

4.

Можно на все положить и сделать нестандартно, но так профессионалы не будут делать. Сделать доступ к программе (не могу назвать это драйвером) через интерфейс /proc. Но так сделать легко. Как это делать подробно изложено здесь:

https://www.iitg.ac.in/asahu/cs421/books/LKM2.6.pdf

 

Т.е. /proc это не профессионально, но советуете книгу чтобы подробней изучить этот метод. А как тогда делают проффесионалы? Изучать примеры реальных драйверов?

На данный момент успел поковыряться с /proc. Действительно, довольно просто.

Книгу пока быстро полистал, там есть и про /dev и /proc, а дальше пока не смотрел.

 

(не могу назвать это драйвером)

Из-за тогоч то нет переносимости?

Ведь драйвер это прослойка между железом и, в конечном счете, пользователем. Т.е. что надо пользователю? Знать какие есть методы, структуры и т.д. в драйвере, чтобы можно легко было взаимодействовать с железом через свою прогу.

 

P.S Про размещение топика учту. Толком не мог определить, куда можно задать свой вопрос.

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Речь не идет о поддается обнаружению. Если в дереве устойств есть и зарегистрирован драйвер, то драйвер ставится и устройство готово работать. Для pug&play устройств тоже надо в дереве описывать. Там просто еще дополнительный механизм.

 

Почему описывают структуру platform device я уже написал. До версии ядра 3.Х.Х все устройства описывались структурами, а после появилось дерево, которое компилируется отдельно и не надо перестраивать ядро.

 

/dev это не то же самое что /proc и /sys две последние примерно одно и то же. первая пришла из юникса. В них отображаются внутренние структуры ядра, а в /dev расположены pipes для связи с устройствами. Все драйвера, к которым нужно иметь доступ из пространства пользователя отображены в /dev.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...