Как использовать файловые модели устройств
Обновлено: 01.07.2024
Эта пятая статья, являющаяся частью серии статей о драйверах устройств Linux, является продолжением различных концепций символьных драйверов и их реализации, рассмотренных в предыдущей статье.
В нашей предыдущей статье мы отмечали, что даже при регистрации для диапазона устройств файлы устройств не создавались в /dev , а Свете приходилось создавать их вручную с помощью mknod. Однако в ходе дальнейшего изучения Света нашла способ автоматического создания файлов устройств с помощью демона udev. Она также изучила второй шаг для соединения файла устройства с драйвером устройства – «Связывание операций файла устройства с функциями драйвера устройства». Вот ее выводы.
Автоматическое создание файлов устройств
Ранее в ядре 2.4 автоматическое создание файлов устройств выполнялось самим ядром путем вызова соответствующих API-интерфейсов devfs. Однако по мере развития ядра разработчики ядра поняли, что файлы устройств в большей степени относятся к пользовательскому пространству, и, следовательно, в соответствии с политикой с ними должны иметь дело только пользователи, а не ядро. С этой идеей теперь ядро заполняет только соответствующий класс устройства и информацию об устройстве в окне /sys для рассматриваемого устройства. И затем пользовательское пространство должно интерпретировать это и предпринять соответствующие действия. В большинстве настольных систем Linux демон udev получает эту информацию и соответственно создает файлы устройств.
udev можно дополнительно настроить с помощью его файлов конфигурации для настройки имен файлов устройств, их разрешений, их типов и т. д. Таким образом, что касается драйвера, соответствующие записи /sys должны быть заполнены с использованием модели устройства Linux. API объявлены в , а все остальное будет обрабатываться udev . Класс устройства создается следующим образом:
и затем информация об устройстве ( ) в этом классе заполняется:
где сначала находится dev_t с соответствующим .
Соответствующие дополнительные или обратные вызовы, которые следует вызывать в хронологически обратном порядке, следующие:
На рис. 9 показаны записи /sys, созданные с использованием «chardrv» в качестве и «mynull» в качестве . Здесь также показан файл устройства, созданный udev на основе записи : в файле dev.
В случае нескольких второстепенных API-интерфейсы device_create() и device_destroy() могут быть помещены в цикл for, и строка может быть полезна. Например, вызов device_create() в цикле for с индексом 'i' может выглядеть следующим образом:
Операции с файлами
Какие бы системные вызовы или, чаще, файловые операции, о которых мы говорим с обычным файлом, также применимы к файлам устройства. Это то, что мы говорим: файл — это файл, а в Linux почти все является файлом с точки зрения пользовательского пространства. Разница заключается в пространстве ядра, где виртуальная файловая система (VFS) декодирует тип файла и передает файловые операции в соответствующий канал, например, модуль файловой системы в случае обычного файла или каталога, соответствующий драйвер устройства в случае устройства. файл. Наш интерес представляет второй случай.
Теперь, чтобы VFS передала операции с файлами устройств драйверу, ей нужно было сообщить об этом. И да, именно это и называется регистрацией файловых операций драйвером с VFS. Это включает в себя два шага. (Текст в скобках ниже относится к коду «нулевого драйвера», который следует за ним.) Во-первых, нужно заполнить структуру файловых операций ( struct file_operations pugs_fops ) желаемыми файловыми операциями ( my_open , my_close , my_read , my_write , …) и инициализируйте структуру символьного устройства ( struct cdev c_dev ) с помощью cdev_init() . Второй шаг — передать эту структуру VFS с помощью вызова cdev_add(). И cdev_init(), и cdev_add() объявлены в . Очевидно, что фактические операции с файлами (my_open, my_close, my_read, my_write) также должны были быть закодированы Shweta. Итак, для начала Светлана сделала их максимально простыми, так сказать, такими же простыми, как «нулевой драйвер».
Нулевой драйвер
Следуя этим шагам, Светлана собрала все воедино, чтобы попробовать свой первый драйвер символьного устройства. Посмотрим, что получилось. Вот полный код:
Затем Светлана повторила обычную сборку с новыми тестовыми шагами следующим образом:
- Создайте драйвер (файл .ko), запустив make.
- Загрузите драйвер с помощью insmod .
- Вывести список загруженных модулей с помощью lsmod .
- Укажите основной номер, выделенный с помощью cat /proc/devices .
- Эксперименты с нулевым драйвером (подробности см. на рис. 10).
- Выгрузите драйвер с помощью rmmod .
Подведение итогов
Светлана, безусловно, была счастлива, так как самостоятельно написала драйвер персонажа, который работает так же, как драйвер для стандартного файла устройства /dev/null . Чтобы понять, что это значит, проверьте сами кортеж для /dev/null , а также попробуйте с ним команды echo и cat.
Но Свету начало беспокоить одно. У нее были собственные вызовы ( my_open , my_close , my_read , my_write ) в ее драйвере, но почему они работают так необычно, в отличие от обычных вызовов файловой системы. Что такого необычного? Что бы я ни писал, я ничего не получаю при чтении — разве это не необычно, по крайней мере, с точки зрения обычных операций с файлами. Есть предположения, как она расколет этот орех? Следите за следующей статьей.
Традиционно, если я хочу создать символьное устройство, мне просто нужно реализовать функции чтения, записи и ioctl и зарегистрировать его с помощью register_chrdev_region с соответствующим основным идентификатором устройства. А затем используйте mknod для создания файла устройства с этим основным идентификатором устройства. Затем вызов read write open в пользовательском пространстве вызовет соответствующие функции ядра.
Но сейчас я изучаю модель устройства Linux и файловую систему sys, которая добавлена в ядро 2.6. Мне сказали, если это возможно, не используйте файловую систему /dev , так как в Linux теперь есть хорошая модель устройства для работы с устройством и драйвером.
- Как создать символьное устройство в /sys? Чтобы быть более конкретным, как мне создать нулевое устройство, такое же, как /dev/null ?
- Как вызвать функцию драйвера символьного устройства из пользовательского пространства?
- Я слышал, что udev основан на файловой системе sys для создания файла устройства в /dev . Почему? Поскольку мне сказали «Если возможно, не используйте файловую систему /dev», почему udev использует /sys для создания файла в /dev?
- Есть ли у файла в sys какие-либо понятия, такие как файл символьного устройства или блочное устройство?
- В /dev открытая запись из пользовательского пространства, наконец, сопоставляется с функциями в структуре операций с файлами, определенной мной, тогда какие функции будут вызываться, когда я открываю или записываю файлы в /ssy ?
1 Ответ 1
Без контекста ваше утверждение о /dev неясно. В любом случае:
Вы не можете создавать символьные устройства в sysfs. Основная цель sysfs — экспортировать информацию и позволить пользователю настраивать отдельные значения (просто перейдите в /sys/ для некоторых примеров). Устройства Char обычно делают много сложных вещей.
Если вы имеете в виду, как вы вызываете open,read,write,ioctl, . ну, выполнив open(2), read(2), write(2), ioctl(2) (посмотрите справочные страницы этих команд)
при появлении устройства ядро создает каталог в /sys. Например, взгляните на ls /sys/bus/usb/devices/. Все эти каталоги создаются при появлении USB-устройства. Вы можете попробовать подключить/отключить USB-устройства. udev присматривается к sysfs для обнаружения новых устройств и, согласно информации от sysfs, создает устройство в каталоге /dev . Это происходит, когда драйвер каким-то образом вызывает device_add(). Часто эта функция вызывается другими функциями регистрации, такими как: device_create , device_register или другие из других подсистем.
идея sysfs заключается в предоставлении информации об устройствах и загруженных драйверах. Таким образом, вы можете изменить параметры устройства, шины и драйвера. Или вручную прикрепить устройство к модулю
На самом деле за атрибутами sysfs скрывается набор файловых_операций, где открытием, чтением и записью управляет ядро, а не ваш драйвер. Чтобы создать атрибут sysfs, вы должны предоставить пару функций show и store для чтения/записи чего-либо из/в драйвер. Затем ядро направит запросы к вашему правильному атрибуту
Раздел Models для каждого производителя идентифицирует как минимум одно устройство, ссылается на раздел DDInstall INF-файла для этого устройства и указывает уникальный для данного устройства раздел модели Идентификатор оборудования (ID) для этого устройства.
Любая запись в разделе Модели для каждого производителя также может указывать один или несколько дополнительных идентификаторов устройств для моделей, которые совместимы с устройством, обозначенным исходным идентификатором оборудования, и управляются теми же драйверами.
В INF-файлах необходимо указать хотя бы один идентификатор устройства для каждой записи в разделе моделей. Это может быть либо идентификатор оборудования, либо совместимый идентификатор.
Записи
device-description
Определяет устанавливаемое устройство, выраженное в виде любой уникальной комбинации видимых символов или токена %strkey%, определенного в INF-файле. Раздел струн. Максимальная длина описания устройства в символах: LINE_LEN.
имя-раздела-установки
Указывает неукрашенное имя разделов установки INF, которые будут использоваться для устройства (и совместимых моделей устройств, если таковые имеются). Дополнительные сведения см. в разделе INF DDInstall.
hw-id
Указывает определяемую поставщиком строку идентификатора оборудования, которая идентифицирует устройство, которое диспетчер PnP использует для поиска соответствия INF-файла для этого устройства.Такой идентификатор оборудования имеет один из следующих форматов:
enumerator\enumerator-specific-device-id
Это типичный формат для отдельных устройств PnP, сообщаемых диспетчеру PnP одним счетчиком. Например, USB\VID_045E&PID_00B идентифицирует клавиатуру Microsoft HID на шине USB. В зависимости от перечислителя такая спецификация может даже включать номер версии оборудования устройства, например, PCI\VEN_1011&DEV_002&SUBSYS_00000000&REV_02 .
*enumerator-specific-device-id
Звездочка (*) указывает, что устройство поддерживается более чем одним перечислителем. Например, *PNP0F01 определяет мышь Microsoft с последовательным интерфейсом, которая также имеет спецификацию совместимого идентификатора SERENUM\PNP0F01 .
Device-class-specific-ID
Специфический для шины ввода-вывода формат, как описано в спецификации оборудования для шины, для аппаратных идентификаторов всех периферийных устройств на этот тип шины ввода/вывода.
Учтите, что одно устройство может иметь более одного значения hw-id. Диспетчер PnP использует каждое такое значение hw-id, которое обычно предоставляется базовой шиной при перечислении своих дочерних устройств, для создания подраздела для каждого такого устройства в ветке реестра Enum. Для устройств, устанавливаемых вручную, код установки системы использует их значения hw-id, указанные в соответствующих INF-файлах, для создания каждого такого подраздела реестра.
идентификатор_совместимости
Указывает определяемую поставщиком строку идентификатора совместимости, которая идентифицирует совместимые устройства. Для записи в разделе Models можно указать любое количество значений compatible-id, отделяя одно от другого запятой (,). Все такие совместимые устройства и/или модели устройств управляются тем же драйвером, что и устройство, обозначенное исходным hw-id.
Примечания
Каждое имя_раздела_моделей должно быть указано в разделе производителя INF файла INF. В разделе Модели для каждого производителя может быть одна или несколько записей, в зависимости от того, сколько устройств (и драйверов) INF-файл устанавливает для конкретного производителя.
Каждое имя раздела-установки должно быть уникальным в INF-файле и должно соответствовать общим правилам определения имен разделов, описанным в разделе Общие правила синтаксиса для INF-файлов. Имя раздела DDInstall, указанное в разделе Models для каждого производителя, также может иметь расширения, добавленные к заданному имя раздела-установки, таким образом определяя дополнительные Разделы DDInstall для установки конкретных устройств для конкретной ОС или платформы. Дополнительную информацию об использовании расширений в межплатформенных системных файлах см. также в разделе Создание INF-файла.
Любое указанное значение hw-id или совместимый-id также можно указать в разделе INF ControlFlags, чтобы предотвратить отображение этого устройства конечному пользователю во время ручного управления. установки. Дополнительную информацию о значениях hw-id и compatible-id см. в разделе Строки идентификации устройства.
Для каждого устройства и драйвера, которые устанавливаются с помощью файла INF, установщики устройства используют информацию, предоставленную в разделе производителя INF и разделах Модели для каждого производителя, для создания описания устройства, имени производителя, Идентификатор устройства (если установка выполняется вручную) и, возможно, записи значения списка совместимости в реестре.
Название раздела models может включать оформление TargetOSVersion. Дополнительные сведения об этом украшении см. в разделе «Производитель INF», в частности в разделе «Примечания».
Важно! Начиная с Windows Server 2003 SP1, файлы INF должны украшать записи имя-раздела-модели в разделе производителя INF вместе с именами связанных разделов Модели INF, с расширениями платформы .ntia64 или .ntamd64, чтобы указать версии целевой операционной системы, отличной от x86. Эти расширения платформы не требуются в файлах INF для версий целевой операционной системы на базе x86 или в файлах INF драйвера, отличного от PnP (например, в файлах INF драйвера файловой системы для архитектур на базе x64). Каждая запись в разделе Модели иногда называется узлом драйвера.
Примеры
В этом примере показан раздел Модели для каждого производителя с некоторыми репрезентативными записями из INF-файла установщика класса системной мыши, определяющими разделы DDInstall для некоторых устройств/моделей.< /p>
В нашей предыдущей статье мы отмечали, что даже при регистрации для диапазона устройств файлы устройств не создавались в разделе /dev, а Свете приходилось создавать их вручную, используя < em>mknod. Однако в ходе дальнейших исследований Света нашла способ автоматического создания файлов устройств с помощью демона udev. Также она изучила второй шаг для соединения файла устройства с драйвером устройства — «Связывание операций файла устройства с функциями драйвера устройства». Вот ее выводы.
Автоматическое создание файлов устройств
Ранее в ядре 2.4 автоматическое создание файлов устройств выполнялось самим ядром путем вызова соответствующих API devfs. Однако по мере развития ядра разработчики ядра поняли, что файлы устройств в большей степени относятся к пользовательскому пространству, и, следовательно, в соответствии с политикой с ними должны иметь дело только пользователи, а не ядро. С этой идеей теперь ядро заполняет только соответствующий класс устройства и информацию об устройстве в окне /sys для рассматриваемого устройства. И затем пользовательское пространство должно интерпретировать это и предпринять соответствующие действия. В большинстве настольных систем Linux демон udev собирает эту информацию и соответствующим образом создает файлы устройств.
udev может быть дополнительно настроен с помощью его файлов конфигурации для настройки имен файлов устройств, их разрешений, их типов и т. д. Таким образом, что касается драйвера, соответствующий /sys записи должны быть заполнены с помощью API моделей устройств Linux, объявленных в , а все остальное будет обработано udev. Класс устройства создается следующим образом:
и затем информация об устройстве ( ) в этом классе заполняется:
где первым является dev_t с соответствующим .
Соответствующие дополнительные или обратные вызовы, которые следует вызывать в хронологически обратном порядке, следующие:
На рис. 9 показаны записи /sys, созданные с использованием «chardrv» в качестве и «mynull» в качестве . Здесь также показан файл устройства, созданный udev на основе записи : в файле dev.
Рисунок 9. Автоматическое создание файла устройства
В случае нескольких второстепенных API-интерфейсы device_create() и device_destroy() могут быть помещены в цикл for, и строка может быть полезна. Например, вызов device_create() в цикле for, индексированном ‘i’, может быть следующим:
Операции с файлами
Какие бы системные вызовы или, чаще, файловые операции, о которых мы говорим с обычным файлом, также применимы к файлам устройства. Это то, что мы говорим: файл — это файл, а в Linux почти все является файлом с точки зрения пользовательского пространства. Разница заключается в пространстве ядра, где виртуальная файловая система (VFS) декодирует тип файла и передает файловые операции в соответствующий канал, например, модуль файловой системы в случае обычного файла или каталога, соответствующий драйвер устройства в случае устройства. файл. Наш интерес представляет второй случай.
Теперь, чтобы VFS передала операции с файлами устройств драйверу, ей нужно было сообщить об этом. И да, именно это и называется регистрацией файловых операций драйвером с VFS. Это включает в себя два шага. (Текст в скобках ниже относится к коду «нулевого драйвера», который следует за ним.) Во-первых, нужно заполнить структуру файловых операций (struct file_operations pugs_fops) нужными файловыми операциями (my_open< /em>, my_close, my_read, my_write, …) и для инициализации структуры символьного устройства (struct cdev c_dev) с помощью cdev_init(). Второй шаг — передать эту структуру VFS с помощью вызова cdev_add(). И cdev_init(), и cdev_add() объявлены в . Очевидно, что фактические операции с файлами (my_open, my_close, my_read, my_write) также должны были быть закодированы Светой. . Итак, для начала Светлана сделала их максимально простыми, так сказать, такими же простыми, как «нулевой драйвер».
Нулевой драйвер
Следуя этим шагам, Светлана собрала все воедино, чтобы попробовать свой первый драйвер символьного устройства. Посмотрим, что получилось. Вот полный код:
Затем Светлана повторила обычную сборку с новыми тестовыми шагами следующим образом:
- Создайте драйвер (файл .ko), запустив make.
- Загрузите драйвер с помощью insmod.
- Список загруженных модулей с помощью lsmod.
- Укажите основной номер, выделенный с помощью cat /proc/devices.
- Эксперименты с нулевым драйвером (подробности см. на рис. 10).
- Выгрузите драйвер с помощью rmmod.
Рисунок 10. Эксперименты с нулевым драйвером
Подведение итогов
Светлана, безусловно, была счастлива, так как самостоятельно написала драйвер персонажа, который работает так же, как и драйвер для стандартного файла устройства /dev/null.Чтобы понять, что это значит, проверьте сами кортеж для /dev/null, а также попробуйте echo и cat. команды с ним.
Но Свету начало беспокоить одно. У нее были собственные вызовы (my_open, my_close, my_read, my_write) в ее драйвере, но как они работают так необычно, в отличие от обычных вызовов файловой системы. Что такого необычного? Что бы я ни писал, я ничего не получаю при чтении — разве это не необычно, по крайней мере, с точки зрения обычных операций с файлами. Есть предположения, как она расколет этот орех? Следите за следующей статьей.
Примечания:
- Для использования фиксированного основного номера вы можете использовать register_chrdev_region() вместо alloc_chrdev_region().
- Используйте версию ядра >= 2.6.3x, чтобы API class_create() и device_create() компилировались должным образом, как описано. Как и до этой версии, они быстро развивались и менялись.
- API ядра (например, class_create(), device_create()), которые возвращают указатели, следует проверять с помощью макроса IS_ERR, а не сравнивать с NULL, так как NULL равно нулю (т. е. успех, а не ошибка). Эти API возвращают отрицательные указатели на ошибку — код ошибки, из которого можно извлечь с помощью PTR_ERR. См. использование в приведенном выше примере.
Другие ссылки:
< br />
< img class="lazyload" data-src="https://sysplay.in/blog/wp-content/plugins/social-autho-bio/images/Twitter.jpg" />
Об Аниле Кумаре Пугалии
29 мыслей на тему “Файлы символьных устройств: создание и использование”
Большое спасибо, мистер Анил Кумар! Я следовал этому замечательному руководству и теперь очень хорошо разбираюсь в драйверах символьных устройств. Еще раз спасибо!
Для меня большая честь, что это помогло вам понять.
Сэр, мой вопрос кажется довольно глупым, но я очень запутался в этом вопросе.
Я прочитал некоторые статьи, но все еще сомневаюсь,
насколько я понимаю, в приведенном выше коде (my_open.my_read,my_write,my_close) мы не выполнили никакой инициализации для параметров функции, таких как *inode, *buf ,*off ,*f и т. д.
Я хотел знать, выполняется ли инициализация параметров VFS или нашим файлом устройства,
так как мы не передавали какие-либо параметры для этих файловых операций.
Это делает VFS, а затем VFS передает это нам — драйверу.
Да, я сомневаюсь, почему вы сделали ” class_create(), device_create() ” в коде драйвера…
этот код является кодом драйвера или кодом устройства (для чего нужен API device_create и почему мы открываем этот /dev/mychar в приложении)
Можете ли вы объяснить это ясно..
С помощью упомянутых вами API-интерфейсов мы просто создаем записи в окне ядра /sys, соответствующие полученному драйверами основному и дополнительному диапазону. Затем информация из записей будет получена демоном udev в пользовательском пространстве для создания соответствующего файла (файлов) устройства, а именно /dev/mynull в статье выше, чтобы приложение могло общаться с драйвером. сквозь это. Для большей ясности ознакомьтесь с предыдущим набором статей, нажав «Предыдущая» в начале этой статьи.
драйвер: проверка модуля не удалась: подпись и/или требуемый ключ отсутствуют – заражение ядра
Я получаю это сообщение в журнале при входе в dmesg. Как мне решить эту проблему?
Какой дистрибутив вы используете? Возможно, конфигурация ядра, используемая для сборки вашего драйвера, настроена на проверку подписи модуля (CONFIG_MODULE_SIG) и не настроена на автоматическую подпись всех модулей (CONFIG_MODULE_SIG_ALL)
как мне это сделать?
Перекомпилируйте ядро после отключения этой опции через menuconfig.
Отличная работа! Продолжайте в том же духе.
Большое спасибо за то, что вы изложили все эти глубокие технические подробности в такой понятной форме в sysplay.in для драйвера устройства Linux.
Спасибо за высокую оценку.
сталкиваюсь с проблемой атомарного создания
не могу заполнить что-то в /sys/class
как отлаживать.
используется 3 API –> class_create(THIS_MODULE”, “char_dev”)
–> device_create(cl,NULL,first,NULL”mynull”)
Какую ошибку вы получаете? Какую версию ядра вы используете?
Здравствуйте, сэр,
Я использую плату разработки NXP MPC8323E-RDB и использую LTIB для ядра Linux и сборки rootfs. Я добавил внешнее оборудование с 4-канальным UART Exar. Я успешно получил доступ к каналам UART 4 с помощью небольшого приложения, сопоставив их адреса. Теперь я пытаюсь написать драйвер для своего устройства uart для транзакций данных. Несмотря на то, что я использую device_create() и class_create() в соответствии с этим блогом, я не получаю /dev/. Мне нужно выполнить шаги, упомянутые в предыдущем блоге, например «mknod /dev/c Major Minor». Почему он так себя ведет?
Я использую ядро 2.6.20-rt8.
Пожалуйста, ответьте как можно скорее.
С уважением и благодарностью,
Шива Пракаш Редди Наредди
В системе работает udev или mdev? Проверьте записи sys для создания записи, а именно /sys/class/class_name/device_name/dev.
Пожалуйста, ответьте на этот запрос
Извините, не посмотрел ответ. Нет, пакет Udev не выбран при сборке ядра. Теперь я выбрал пакет udev в конфигурации ядра и собрал его. Это не удалось из-за отсутствия поддерживающих пакетов, таких как «Hotplug». позвольте мне проверить, установив дополнительные пакеты.
Я внедрил драйвер в соответствии с вашим отличным руководством, но хотя /sys/class.. заполнен. Устройство не отображается в каталоге /dev. Я создал устройство с помощью device_create_with_groups.
Как вы думаете, в чем может быть проблема?
Вы проверили возвращаемое значение device_create_with_groups с помощью IS_ERR? С большой долей вероятности выдает ошибку. Если да, исправьте.
Отличная статья о создании и работе с файлами устройств!
У меня есть вопрос относительно функции device_create(). Насколько я понимаю, device_create() создает запись устройства с указанным именем устройства в каталоге /sys/class/ и запускает событие uevent, из-за которого Udev создает узел устройства в каталоге /dev.
Но что, если мы намерены создать узел устройства только тогда, когда подключено указанное оборудование?
Просто мысль: что, если мы ограничим device_create() только созданием записи устройства в /sys, но не созданием узла устройства, и отредактируем правила udev таким образом, чтобы при каждом подключении соответствующего оборудования узел устройства создавался с то же имя, что и запись в каталоге /sys? Это возможно ? Если да, то как мы можем этого добиться?
Чтобы Google Ассистент мог реагировать на команды, соответствующие вашему устройству и заданному контексту, ему нужна информация о вашем конкретном устройстве. Вы предоставляете эту информацию, которая включает в себя такие поля, как тип устройства и производитель, в качестве модели устройства. Эту модель можно рассматривать как общий класс устройств, например свет, динамик или игрушечный робот.
Эта информация становится доступной для помощника и связывается с вашим проектом Actions Console. Никакие другие проекты не имеют доступа к вашей модели и информации об устройстве.
Используйте интерфейс регистрации
Используйте интерфейс регистрации в Actions Console, чтобы зарегистрировать модель устройства.
Нажмите кнопку ЗАРЕГИСТРИРОВАТЬ МОДЕЛЬ.
Создать модель
Заполните все поля для вашего устройства. Выберите любой тип устройства, например Light.
Дополнительную информацию об этих полях см. в справочнике JSON модели устройства.
Когда закончите, нажмите ЗАРЕГИСТРИРОВАТЬ МОДЕЛЬ.
Загрузить учетные данные
Файл client_secret_.json должен находиться на устройстве. Этот файл содержит идентификатор клиента и секрет клиента, но не содержит токена доступа. Позже вы запустите инструмент авторизации и сошлетесь на этот файл, чтобы авторизовать образец Google Assistant SDK для выполнения запросов Google Assistant (дополнительную информацию см. в документации по OAuth 2.0). Не переименовывайте этот файл.
Загрузите этот файл и перенесите его на устройство. Нажмите ДАЛЕЕ.
Только для Raspberry Pi
Убедитесь, что этот файл находится в /home/pi . Если вы хотите загрузить файл на устройство, сделайте следующее:
Откройте новое окно терминала. Выполните следующую команду в этом новом терминале:
Закройте это окно терминала.
Указать черты
Позже на этом экране вы укажете различные возможности, поддерживаемые вашим устройством. А пока нажмите кнопку ПРОПУСТИТЬ.
Редактировать модель
Если вам нужно отредактировать модель, щелкните ее строку в списке. Обязательно нажимайте СОХРАНИТЬ после любых изменений.
Если вам нужно снова загрузить файл учетных данных, щелкните многоточие. Вы также можете удалить модель из этого меню.
Альтернативные способы регистрации
Для регистрации модели устройства вы также можете использовать инструмент регистрации (входит в состав примеров Google Assistant SDK) или REST API.
Вы должны быть владельцем или редактором данного проекта Actions Console, чтобы регистрировать для него модели. Добавьте эти роли для других пользователей в Cloud Platform Console — см. документацию IAM.
Следующий шаг
Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.
Читайте также: