Когда использовать / dev и / sys для пользовательского пространства-ядра связи?
Это зависит от того, что в виде знака доллара $ - расширяется до списка текущего набора оболочки ] однобуквенные параметры таблицы, такие как -x и -f и -C . Например, интерактивная оболочка расширяет его как минимум , например:
echo "$-"
i
Чем длиннее, set -o option версии можно получить с помощью set + o.
Но есть еще один вид особого-дефисного параметра , который является своего рода аналогом этого. Вы можете использовать два последовательных дефиса для обозначения конца параметров в типичном списке аргументов команды, но вы также можете использовать одинарный дефис, чтобы сделать то же самое для POSIX-оболочки. Исторически сложилось так, что снаряды принимали одинарный дефис как почти то же самое.
Оболочка bash интерпретирует одинарный дефис специально в контекстах списка аргументов.При установке , например, он отмечает конец параметров , а отключает -v erbose и -x trace. Кроме того, set - не очищает список параметров, если это первый и единственный аргумент для set как set - будет.
Оболочка входа часто добавляет - к своему argv [0] .
Очень приблизительно:
/devсодержит узлы устройств, которые в более ранних системах Unix были единственным способом взаимодействия с ядром. Существует два типа таких устройств: блочные устройства и символьные устройства. Соответствующий API предназначен для чего-то, что позволит осуществлять блочный -ввод-вывод (, какой-то дисковый )или символьный ввод-вывод (, например. последовательный порт ).
/sys(и/proc)были добавлены позже, возможно, вдохновленные операционной системой Plan 9 . Они предоставляют полные поддеревья каталогов, а записи файлов в этих поддеревьях содержат текст, который описывает внутреннее состояние модуля ядра при чтении или, при записи, устанавливает внутреннее состояние.
Таким образом, типичным приложением будет:
Вы хотите написать драйвер ядра для какого-нибудь запоминающего устройства? Используйте узел /devдля доступа к самому устройству и записи/sys(или/proc)для точной -настройки доступа к хранилищу.
Описание /sysсодержится в главе 14, "Модель устройства Linux". Он предоставляет еще несколько примеров кода для игры. Но я полагаю, что книга больше ориентирована на -код, и полезно спросить, как выглядят принципы проектирования.
Когда использовать /dev и /sys для взаимодействия с ядром -пользовательского пространства?
Самый первый ответ заключается в том, что вы не выбираете себя. Когда вы пишете драйвер для устройства определенного типа, в ядре уже есть много примеров устройств одного и того же типа. Вы используете шаблоны кода, эквивалентные существующим устройствам. (Самой актуальной документацией является сам код. Многие интерфейсы ядра не имеют полной или датированной -до -документации, извините!)
Это основная причина написания драйверов устройств. Вы предоставляете согласованные интерфейсы, которые могут использовать программы, без необходимости кодировать разные детали для каждого отдельного устройства.
Это преобладает над любыми более общими советами. Если подсистема Linux (, то есть тип устройства ), использует метод, который кажется «неправильным», но делает это последовательно, вы также должны быть последовательными и «неправильными» при написании драйвера для этой подсистемы.
/dev
В качестве пути к данным следует использовать /dev/. За исключением сетевых устройств, которые рассматриваются в другом разделе книги.
Для стандартизированных операций unix следует использовать специальные файлы /dev/ :read(), write(), poll()/ select(), mmap(). Также желательно, чтобы ioctl()были эффективно стандартизированы в unix или linux. Эти несколько системных вызовов (и несколько производных вариантов )используются почти во всех случаях. Начните знакомиться с ними :). ioctl()— это аварийный люк, который можно использовать, чтобы позволить вашему водителю определить любое количество других операций.
/систем
Записи sysfs следует использовать в гораздо меньшем количестве случаев для параметров конфигурации. Они должны быть в текстовом формате,и должен содержать только одно значение.[ *] Вам не захочется иметь слишком много разных файлов sysfs. Вы можете начать видеть их ограничения довольно быстро.
Мы также можем сказать, что файлы sysfs должны в основном считывать переменную (, которая также может быть или не быть доступной для записи ). Я думаю, что их чтение не должно вызывать каких-либо аппаратных операций. Я полагаю, что вы уже думали в этом направлении.
Преимущество файлов sysfs заключается в том, что с ними очень удобно экспериментировать. Вы можете легко использовать команды оболочки для их перечисления, чтения и записи. Это также опасно :, вы должны быть осторожны, чтобы не публиковать файлы sysfs в экспериментальном состоянии. Как только другие люди начнут полагаться на ваш файл sysfs, сопровождающие ядра будут крайне недовольны, если вы захотите что-то изменить каким-то образом, который нарушит пользовательские сценарии.
Обход sysfs -иерархии каталогов и символических ссылок -также может быть полезен, чтобы увидеть, как организованы устройства.
Кроме того, концептуальное наблюдение за изменениями в sysfs заключается в том, как программы могут обнаруживать новые устройства (, например. при подключении ). Технически эти события не доставляются через саму файловую систему, но каждое событие указывает на определенный каталог sysfs.
Демон udev отслеживает эти события; нормальные программы должны, как правило, полагаться на udev/libudev, если им это необходимо. Например, правила udev могут читать или записывать некоторые файлы в каталоге sysfs при получении события, например. для изменения настроек на вновь обнаруженных устройствах.
Просмотр примеров
Рассмотрение существующих примеров — чрезвычайно хорошая идея. Хотя вам, вероятно, не следует рассматривать только один пример и предполагать, что он работает одинаково везде :-).
Как говорит dirkt, доступ к блочным устройствам хранения, таким как /dev/sda, является очень стандартизированным использованием /dev.Некоторые параметры, такие как максимальный физический размер ввода-вывода, указанные в /sys/class/block/sda/-, можно найти в подкаталоге queue.
Многие файлы sysfs задокументированы в дереве ядра, Documentation/ABI/*/sysfs-*. Например:https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block
Обратите внимание, что «символьное устройство» не очень конкретное. Он используется практически для любого устройства, которое не является ни блочным, ни сетевым :-). Если бы вам когда-либо приходилось реализовывать какой-то совершенно новый класс устройств, вам, вероятно, пришлось бы определять совершенно новый тип символьных устройств и выполнять ужасающую работу по определению какого-то нового набора ioctl()операций.
Вы можете начать поиск в /sys/class/, чтобы увидеть некоторые другие типы устройств, которые определены в вашей собственной системе.
/sys/также включает список /dev/устройств, но он указан по номеру устройства, а не по имени. См. ls -l /sys/dev/char/и ls -l /sys/dev/block/. Это помогает объяснить, как udevможет управлять/dev:каждым устройством, которое появляется в /dev, указано как объект в /sys. [**]
[ *] sysfs ueventфайлы содержат несколько значений и на самом деле являются основной функцией. но файл uevent нельзя использовать для изменения значений внутри. Так что я просто говорю :не смотрите на ueventи не думайте, что мой совет неверен; вы не должны определять такой файл самостоятельно. Драйвер устройства может добавлять строки в свой файл uevent; Я думаю, хорошим примером может быть наличие некоторых очень полезных идентифицирующих свойств, которые udevправило хочет проверить.
[ **] За исключением /dev/pts/0и т. д., они не перечислены в /sys, потому что /dev/pts/0фактически реализуется отдельной файловой системой "devpts". Пожалуйста, игнорируйте /dev/pts/0как очень, очень особый случай. Есть ответ, в котором я пришел к этому выводу, но я действительно не думаю, что он что-то добавляет к тому, что я только что сказал. Это здесь:Всегда ли используется TTY, когда мы открываем любой терминал? .