Pts linux что это
Русские Блоги
Обзор Linux TTY / PTS
Справочник статей
1. История TTY
1.1 До появления многозадачных компьютеров
До того, как компьютер вышел, люди уже использовали устройство, называемое телетайп, для передачи информации между собой, которая выглядит следующим образом:
Два телетайпа соединены кабелем. На обоих концах кабеля могут быть устройства, похожие на модемы (не указывайте их здесь). Когда вы набираете клавиатуру на телетайпе на одном конце, соответствующие данные будут отправлены телетайпу на другом конце. Я не знаю много о функции. (Я думаю, в моей голове, что изображение напечатано на одном конце и напечатано на другом конце)
1.2 После появления компьютеров, поддерживающих многозадачность
После того, как компьютер поддерживает многозадачность, люди думают о подключении этих телетипов к компьютеру как к компьютерному терминалу, который может управлять компьютером.
Есть две основные причины использования телетайпа (личное мнение):
На самом деле уже существует большое количество телетайпов разных производителей, которые могут в полной мере использовать имеющиеся ресурсы
Сеть телетайпа является относительно зрелой, и ее удобно подключать.
Таким образом, связь развивается так:
Модем используется по обе стороны от физической линии, что мы часто называем «кошкой», потому что сеть постепенно развивается, и каждый может разделить соединение. (Предположительно, это может быть неправильно)
UART можно понимать как устройство, которое преобразует сигнал телетайпа в сигнал, распознаваемый компьютером.
1.3 Подсистема ядра TTY
Для поддержки этих телетайпов компьютер спроектировал подсистему с именем TTY со следующей внутренней структурой:
Интерфейс драйвера UART с внешним устройством UART
Линейная дисциплина в основном заключается в некоторой обработке входных и выходных данных, можно понять, что она является частью драйвера TTY
Драйвер TTY используется для обработки различных оконечных устройств
Процессы в пользовательском пространстве взаимодействуют с терминалом через драйвер TTY
Для простоты драйвер UART и дисциплина Line не перечислены отдельно в следующем введении, их можно рассматривать как часть драйвера TTY
1.4 TTY оборудование
Для каждого терминала драйвер TTY создаст соответствующее ему устройство TTY. Если подключено несколько терминалов, это выглядит так:
Когда драйвер получает терминальное соединение, он создаст соответствующее tty-устройство в соответствии с моделью и параметрами терминала (имя устройства на рисунке выше называется ttyS0, потому что большинство терминальных соединений являются последовательными соединениями), потому что каждый терминал может Не то же самое, с их собственными специальными командами и привычками использования, поэтому конфигурация каждого устройства tty может быть разной. Например, когда вы нажимаете клавишу удаления, некоторые могут удалить предыдущий символ, а некоторые могут удалить задний символ. Если вы не сконфигурируете права, это приведет к тому, что некоторые клавиши не будут соответствовать вашему желанию. Это также, когда мы используем аналоговый терминал. Если конфигурация по умолчанию не соответствует нашим привычкам, вам необходимо выполнить некоторые личные настройки.
Позже, с непрерывным развитием компьютеров, эти типы оборудования телетайпа постепенно исчезли. Нам больше не нужно специальное оконечное оборудование. У каждой машины есть своя клавиатура и дисплей. Каждая машина может быть терминалом других машин. ssh для достижения, но архитектура драйвера TTY ядра не изменилась. Мы хотим взаимодействовать с процессами в системе через ввод-вывод, или нам нужно пропустить устройство TTY, поэтому появилось различное программное обеспечение эмуляции терминала, и эмуляция также распространена. Несколько терминалов, таких как VT100, VT220, XTerm и др.
Вы можете использовать команду infocmp для сравнения различий между двумя терминалами, например, infocmp vt100 vt220 выведет разницу между vt100 и vt220.
2. Как программа работает с TTY
Прежде чем обсуждать, как создаются и настраиваются устройства TTY, давайте посмотрим, как TTY используется процессами:
Сначала используйте команду tty, чтобы увидеть, с каким tty связан текущий bash
Посмотрите, какие процессы открыты tty
Запись данных напрямую в tty имеет тот же эффект, что и запись стандартного вывода
[email protected]:
$ echo aaa > /dev/pts/8
aaa
Оч тоже tty устройство, и их отношения будут представлены позже
Как видно из вышеприведенного lsof, stdin (0u), stdout (1u) и stderr (2u) текущих процессов bash и lsof связаны с этим TTY.
Ниже приведена структурная схема взаимодействия между tty и процессом и устройством ввода-вывода:
Tty можно понимать как канал, а содержимое, записанное на одном конце, может быть прочитано с другого конца, и наоборот.
Здесь ввод и вывод могут быть просто поняты как клавиатура и монитор, и то, что будет связано с вводом / выводом в различных ситуациях, будет описано позже.
В tty есть очень важный атрибут, называемый группой процессов Foreground, который записывает текущую интерфейсную группу процессов. Концепция группы процессов будет представлена в следующей статье, где мы можем просто подумать, что в группе процессов есть только один процесс.
Когда pts / 1 получает входные данные от входа, он проверяет, какая из них является текущей внешней группой процессов, а затем помещает входные данные во входной буфер лидера группы процессов, чтобы соответствующий процесс лидера мог получить ввод пользователя через функцию чтения.
Когда процессы в группе внешних процессов записывают данные на tty-устройство, tty выводит данные на устройство вывода
При выполнении различных команд в оболочке группа внешних процессов постоянно меняется, и это изменение будет обновляться оболочкой на устройстве tty.
Из вышесказанного видно, что процесс и tty очень просты, если фоновый процесс не читает или не записывает tty, то есть при написании фоновой программы вы должны перенаправить stdin / stdout / stderr в другие места (конечно, программе deamon необходимо сделать Многие другие процедуры).
Сначала киньте два вопроса (ответ есть позже):
3. Как был создан TTY
Далее описывается, как создать tty-устройство в нескольких распространенных ситуациях, и каковы устройства ввода и вывода.
Монитор клавиатуры подключен напрямую (терминал)
Посмотрите на картинку, прежде чем говорить:
Клавиатура и монитор подключены к эмулятору терминала в ядре. Эмулятор определяет количество создаваемых ttys. Например, когда вы набираете ctrl + alt + F1 на клавиатуре, эмулятор сначала захватывает ввод, а затем активирует tty1, чтобы ввод с клавиатуры Он будет перенаправлен на tty1, а вывод tty1 будет перенаправлен на дисплей.Так же, используйте ctrl + alt + F2 для переключения на tty2.
Когда эмулятор активирует tty, если он обнаруживает, что с ним не связан ни один процесс, это означает, что он впервые открывает tty, поэтому он запустит сконфигурированный процесс и свяжется с tty. Обычно процесс является процессом, ответственным за вход в систему.
При переключении на tty2, где будет выводиться вывод в tty1? Вывод tty1 по-прежнему будет выводиться в эмулятор. В эмуляторе будет кэш каждого tty. Однако из-за ограниченного пространства кэш-памяти эмулятора, когда вы в следующий раз вернетесь к tty1, вы сможете увидеть только самый последний вывод, предыдущий вывод Ушел
Не уверен, какому конкретному модулю в ядре соответствует эмулятор терминала, но должна быть такая вещь
4. SSH удаленный доступ
Терминал здесь может быть программой из любой точки мира, например, замазкой в Windows, поэтому я не буду обсуждать, как клиентская программа терминала взаимодействует с клавиатурой и дисплеем. Так как Терминал должен иметь дело с сервером ssh, он должен реализовать клиентскую функцию ssh.
Здесь установление соединения, а также отправка и получение данных объясняются в двух строках.Для краткого описания вместо программы ssh-сервера используется sshd:
4.1 Установление связи
Терминал просит установить соединение с sshd
Если проверка пройдена, sshd создаст новый сеанс
Вызовите API (posix_openpt ()), чтобы запросить ptmx для создания pts. После успешного создания sshd получит fd, связанный с ptmx, и свяжет fd с сеансом.
# Здесь видно, что sshd открыл / dev / ptmx
4.2 Отправка и получение сообщений
Терминал получает ввод с клавиатуры, а Терминал отправляет данные в sshd по протоколу ssh.
После получения данных от клиента sshd находит соответствующий fd на ptmx, соответствующий клиенту, в соответствии с сеансом, которым он управляет.
Запишите данные, отправленные клиентом в найденный файл
После получения данных ptmx находит соответствующие точки в соответствии с fd (соответствующая взаимосвязь автоматически поддерживается ptmx) и перенаправляет пакет данных в соответствующие точки
После получения пакета данных pts проверяет текущую группу внешних процессов, связанную с ним, и отправляет пакет данных руководителю группы процессов.
Поскольку на pts есть только оболочка, функция чтения оболочки получает пакет
Оболочка обрабатывает полученные пакеты данных, а затем выводит результаты обработки (может не выводиться)
Оболочка записывает результат в pts через функцию записи
pts пересылает результат в ptmx
ptmx находит соответствующий fd согласно pts и записывает результат в fd
После получения результата fd sshd находит соответствующий сеанс и отправляет результат соответствующему клиенту.
5. Монитор клавиатуры подключен напрямую (графический интерфейс)
6. Разница между TTY и PTS
Из вышеприведенного процесса должно быть видно, что для программ пользовательского пространства они ничем не отличаются, они одинаковы: из ядра другой конец pts подключен к ptmx, а другой конец tty подключен Это эмулятор терминала ядра. Как ptmx, так и эмулятор терминала отвечают только за поддержание сеансов и пересылку пакетов данных, посмотрите на другой конец ptmx и эмулятор терминала ядра. Другой конец ptmx подключен к приложениям пользовательского пространства, таким как sshd Tmux и т. Д., А другой конец эмулятора терминала ядра подключен к определенному оборудованию, например клавиатуре и монитору.
7. Общая конфигурация TTY
7.1 rows 51; columns 204;
Эта конфигурация обычно контролируется терминалом. Когда размер окна терминала изменяется, конфигурация должна быть изменена определенными средствами. Например, есть параметр для изменения размера окна в протоколе ssh. После получения запроса клиента sshd изменит tty через API Этот параметр затем сообщается tty внешней программе (такой как shell или vim) через сигнал SIGWINCH.После получения сигнала внешняя программа считывает этот параметр tty и затем знает, как отрегулировать свою схему вывода.
7.2 intr = ^C
В дополнение к пересылке данных между терминалом и внешним процессом tty также поддерживает множество команд управления. Например, если терминал вводит CTRL + C, tty не пересылает входную строку во внешний процесс, но преобразует ее в сигнал SIGINT и отправляет ее. Дай фронтэнд процесс. Это используется для настройки входной комбинации, соответствующей команде управления. Например, мы можем настроить «intr = ^ E» для использования CTRL + E вместо CTRL + C.
Виртуальные твари и места их обитания: прошлое и настоящее TTY в Linux
Ubuntu интегрирована в Windows 10 Redstone, Visual Studio 2017 обзавелась поддержкой разработки под Linux – даже Microsoft сдает позиции в пользу растущего числа сторонников Торвальдса, а ты всё еще не знаешь тайны виртуального терминала в современных дистрибутивах?
Хочешь исправить этот пробел и открываешь исходный код? TTY, MASTER, SLAVE, N_TTY, VT, PTS, PTMX… Нагромождение понятий, виртуальных устройств и беспорядочная магия? Всё это складывается в довольно логичную картину, если вспомнить, с чего всё началось…
1. START FROM SCRATCH & KEEP CALM
TTY: ПАЛЕОЗОЙ
Мы шагнули прямиком в тридцатые годы XX века и оказались в совсем еще молодой Teletype Corporation. Прямо перед нами перед нами Тот-С-Которого-Всё-Началось – телетайп, представляющий из себя «буквопечатающий телеграф», который передает текстовые сообщения между двумя абонентами.
Абонент А набирает на клавиатуре символы, которые преобразуются в электрические сигналы. По самому обычному кабелю сигналы «бегут» на телетайп абонента Б и уже там печатаются на самой обычной бумаге. Если сигнал дуплексный, то нам крупно повезло, и абонент Б может сразу написать свой ответ; если нет – то ему потребуется сначала подсоединить второй провод для обратной связи.
Здесь, на Teletype Corporation, еще не знают, какое будущее в скором времени ждет их продукт, и уж конечно не подозревают, что аббревиатура TTY намного переживет сам телетайп. Не будем портить для них интригу, пойдем дальше.
TTY: МЕЗОЗОЙ
Прошло сорок лет, мы в лаборатории Digital Equipment Corporation, любуемся первым мини-компьютером (интерактивным!) PDP-1. Для ввода и вывода информации, а также для обеспечения взаимодействия с пользователем к нему подключен уже знакомый нам телетайп.
Дело в том, что ведущие инженерные умы решили велосипед не изобретать и приспособить уже имеющийся дешевый и доступный механизм под новые нужды. Телетайп напрямую подключили к компьютеру (а не к другому телетайпу, как это было раньше) и назвали это дело консолью. Оператор, осуществляющий ввод, видит, как набираемые символы мгновенно печатаются на бумаге, но происходит это без участия ОС – благодаря сохранению в консоли принципа печатающей машинки.
TTY: ПАЛЕОГЕН
Оказываемся в самом начале 80-ых годов, на этот раз в Bell Laboratories. Здесь только что выпущен один из важнейших релизов «раннего» UNIX – Version 7 для PDP-11. Особенности у этого релиза следующие: вводимая пользователем команда теперь отображается по принципу ECHO (набранный на клавиатуре символ сначала попадает в буфер накопления и только потом ОС отправляет инструкцию вывести этот символ на печать), поддерживаются простые возможности редактирования вводимых команд (можно «стирать» символ или целую строку, перемещать каретку), появляется разделение режимов:
Кстати говоря, Digital Equipment Corporation за эти 20 лет не только разработала упомянутый PDP-11, но и подумала о том, как усовершенствовать телетайп: появились так называемые умные терминалы.
Смотрим направо: это VT100, один из первых терминалов, умеющих работать в любви и согласии с PDP-11 и поддерживаемый Unix Version 7.
На уровне ОС и консоль, и умный терминал сейчас воспринимаются как символьные устройства, которые подключаются через интерфейс UART, преобразовывающий асинхронный поток данных в последовательность символов. Для ОС они в принципе идентичны, разница лишь в том, стирать ли символы на экране терминала или печатать символ забоя с помощью телетайпа.
Слева показана в общих чертах схема взаимодействия компьютера и консоли (или умного терминала). У этой схемы есть один недостаток, который совсем не радует оператора консоли PDP-11: с одной консолью ассоциируется одна сессия (или сеанс), в котором пользователь может в фоновом режиме запустить несколько процессов, однако активным в один момент времени на одном TTY будет только один.
И наш бедный оператор вынужден в прямом смысле этого слова переходить от одной консоли к другой, если вдруг ему придет в голову поработать с несколькими сессиями.
TTY: НЕОГЕН
Мы очутились в редакции журнала «PC MAGAZINE», рассматриваем свежий выпуск от 13 января 1987 года. Один из разворотов активно убеждает нас не жалеть денег на ПК с UNIX System V. Каковы аргументы? В частности – grep, awk, sort, split, cut, paste, vi, ed – word processing явно шагнул вперед. И самое интересное: к нашим услугам сейчас эмуляторы терминалов! Благодаря виртуальным консолям, уже можно запустить целых четыре сессии без нужды подключать всё новые и новые физические телетайпы.
Кроме того, жизнь монохромных терминалов нынче можно расцветить: поддерживается CGA, Hercules, EGA графика. Бедолага-оператор может вздохнуть спокойно, телетайп (а также умный терминал) в виде железного зверя угрожает ему только в ночных кошмарах.
Посоветуем оператору лишь одно: ни за что не лезть в директорию /dev – ведь его ждут там аж несколько ttyX и напоминают о том, что под капотом виртуальной консоли живет всё тот же старый-добрый телетайп.
TTY: АНТРОПОГЕН
На предыдущем шаге мы убедились: консоль сделали виртуальной (не будет же солидное издание «PC MAGAZINE» лгать). Что это значит – весь механизм ввода/вывода переписан и в корне изменен? Тогда почему виртуальное устройство – всё еще ttyX? Всё просто: виртуальная консоль эмулируется как самая что ни на есть физическая, а место UART-драйвера, вероятно, занимает кто-то другой. Изменившуюся схему подробно обсудим чуть дальше.
До финишной прямой один шаг, но пропустить его мы не можем хотя бы из уважения к Линусу Торвальдсу. Сейчас 1993 год, и мы наконец имеем счастье рассматривать исходный код Linux 0.95. Почему именно этот релиз? Именно в нем уже сформировалась TTY-абстракция, наиболее близкая к тому, что мы имеем в самых последних дистрибутивах: оформились три обособленных слоя (TTYX — TTY_LINE_DISCIPLINE — TTY_DRIVER).
Кроме того, спустя всего год будет выпущен Linux 1.0, где появится оконный интерфейс, предоставленный проектом XFree86. С этого момента к виртуальным консолям добавятся в придачу еще виртуальные терминалы, которые пользователь (в почти не ограниченном количестве) сможет запускать, не покидая графическую оболочку… Однако прежде, чем окунуться в тонкости и детали усовершенствованной io-магии, вернемся в наше настоящее к Ubuntu 16.04.
2. STOP BEAT AROUND THE BUSH & LOOK INSIDE
ВИРТУАЛЬНЫЕ ТВАРИ И МЕСТА ИХ ОБИТАНИЯ
Лишь некоторые устройства директории /dev/ используются повседневно: /dev/sdaX, /dev/mem, /dev/zero, /dev/random… Но есть несколько групп устройств, которые не часто привлекают наше внимание, однако более чем его заслуживают. Это устройства /ttyX, /vcsX, /vcsaX, а также /ptmx и /pts/X. Собственно говоря, о них и пойдет речь дальше.
И первый наш объект – виртуальная консоль. Каждому такому объекту присущи как минимум сакральное число идентификатор и тотемное животное файл виртуального устройства /tty, коих в виртуальном лесу директории /dev встречают аж 64.
Проверим, есть ли у нас возможность пообщаться с ними. Выполняем Ctrl-Alt-FX (или chvt X, где X – номер консоли, например, Ctrl-Alt-F1) и замечаем, что X может быть равно 1, 2 … 6. При этом перед нами открывается виртуальная консоль, при первом запуске нам предлагают ввести имя пользователя и пароль и создают для нас новый сеанс работы. Если X равен 7, то мы возвращаемся в родные графические пенаты и понимаем, что /tty7 связан с XServer’ом. Идем дальше. Восемь, девять, десять и так далее до 63 — признаков жизни не подают.
Дело в том, что в Linux есть макрос MAX_NR_CONSOLES (64), определяющий максимально допустимое число виртуальных консолей, которые и представлены 64-мя файлами виртуальных устройств /dev/ttyX. Однако последнее слово остается за параметром ACTIVE_CONSOLES (/etc/default/console-setup), и параметр этот по умолчанию равен шести.
Инициализация консолей происходит в несколько стадий. Сперва ядро, получив управление от Grub’a, в ходе инициализации подсистем вызывает функцию «console_init», которая создает первичную консоль – «boot console», предназначенную для вывода отладочной информации. Это консоль осуществляет вывод символов самым примитивным образом: через «putchar», которая напрямую обращается к BIOS, инициализируя и заполняя структуру biosregs, и осуществляет вывод символа в консоль, используя прерывание 0x10.
Позже, в ходе выполнения «fs-initcall» и «console-initcall» происходит создание виртуальных устройств и структур под 6 полноценных виртуальных консолей – «real console». Активацию этих консолей выполняет первый запущенный ядром процесс /sbin/init, запускающий программу getty, которая выполняет чтение конфигурационных файлов /etc/init/console.conf и /etc/init/ttyX.conf и впоследствии отображает на консоль содержимое файла-приветствия etc/issue и запускает login. Далее XServer инициирует активацию консоли на dev/tty7, на которой запускается графическая оболочка.
Однако у нас есть еще вопросы. Что за неведомый объект /dev/tty0? И если каждый /dev/ttyX — это виртуальное устройство консоли, то зачем нужны /dev/console и /dev/tty? За ответом переходим на tty1 (нажимая Ctrl-Alt-F1) и в фоновом режиме запускаем такой скрипт:
Затем переходим на, скажем, tty4 и ждем несколько секунд. По истечении видим следующую картину:
Распределение ролей становится понятно: /dev/tty0 = /dev/console = текущая консоль, т.е. оба всегда ассоциированы с той консолью, которую мы в данный момент видим перед собой, а /dev/tty «помнит» консоль, с которой стартовал процесс. Поэтому пока наш процесс выполнялся, /dev/tty0 и /dev/console определялись для него по ходу пьесы в зависимости от текущей активной консоли, а вот /dev/tty оставался неизменным.
Не спешим покидать директорию /dev. Здесь еще чуть больше дюжины любопытных объектов: /dev/vcsX (virtual console screen) и /dev/vcsaX (virtual console screen with attributes). Еще один опыт: перемещаемся на tty5 и оставляем какие-нибудь следы своего пребывания, затем переходим в любую другую консоль (пусть ее номер 3), делаем «cat» на /dev/vcs5 и видим именно то состояние консоли 5, в каком мы оставили ее несколько секунд назад. При этом, соответственно, /dev/vcs3 и /dev/vcs (а также /dev/vcsa) относятся к консоли 3, на которой мы находимся в данный момент.
Понимаем, что /dev/vcsX — не что иное как омут памяти устройство виртуальной памяти консоли, позволяющее нам без потерь перемещаться между экземплярами tty. В паре с ним — /dev/vcsaX, который предоставляет базовые сведения о состоянии экрана: цвета, различные атрибуты (напр. мерцание), текущее положение курсора, конфигурацию экрана (количество строк и столбцов). Подытожим увиденное схемой:
ВИД СВЕРХУ ЛУЧШЕ
Теперь остановимся с изучением зоологии tty на какое-то время и перейдем к самой tty-абстракции, частью которой и являются наши виртуальные устройства. Посмотрим на общую структуру tty-комплекса и выделим три компонента:
При этом процессы от первого tty продолжают работать: считывают команды с файла своей виртуальной консоли, пишут в этой файл, но – так как они оторваны от «кресла» – не получают никаких событий (те же ^C и ^Z) и – так как физические устройства «уехали» вместе с «креслом» – могут только накапливать свой «вывод» в буфере, чтоб отправить его на монитор, как только «кресло» вернется.
ПУТЕШЕСТВИЕ К ЦЕНТРУ ЗЕМЛИ
Да, сверху всё смотрится вполне презентабельно. Но тебе, %username%, вероятно, хочется увидеть, как трехуровневое взаимодействие tty-компонентов реализовано непосредственно в коде? За ответом придется опуститься с небес на землю, даже лучше сказать – под землю, в недра исходного кода Ubuntu (работать будем с ядром версии 4.4).
Сделаем упреждающий ход – разберемся, через какие структуры происходит связывание tty-абстракции в единое целое.
Во-первых, это «tty_struct», у которой есть поле «tty_ldisc» (это структура методов драйвера 2-ого слоя), поле «tty_driver» (это драйвер 3-ого слоя) и тут же «tty_operations» (это структура методов драйвера 3-ого слоя, ради удобства вынесенная прямо в «tty_struct»).
То есть, «tty_struct» обеспечивает доступ к слоям TTY_LINE_DISCIPLINE и TTY_DRIVER. Получили к ней доступ – 2/3 стека tty-абстракции, считай, перед нами. Теперь нам нужно понять, как осуществляется переход от файлов виртуальных устройств к этой самой структуре. Ответ прост: у структуры «tty_file_private» как раз есть поле типа «tty_struct». Следовательно, обращаясь к файлу виртуального устройства на 1-ом уровне, мы с легкостью получаем доступ к уровням повыше.
Пока пазл складывается, но нам этого недостаточно. Продебажим ядро (с помощью qemu и cgdb) и рассмотрим backtrace вывода (эхо) единичного символа, введенного пользователем с клавиатуры:
Итак, мы на I уровне tty-стека. Происходит системный вызов «write», который на нашем tty обрабатывается функцией «tty_write». В нее передаются указатель на структуру файла виртуального устройства и буфер с символом. В функции «tty_write» по файлу происходит получение экземпляра «tty_struct». Принимая игру, «tty_struct» первым делом вызывает драйвер TTY_LINE_DISCIPLINE – «tty_ldisc», место которой по умолчанию занимает N_TTY. Первый уровень пройден!
N_TTY принимает эстафету: в свою очередь вызывает метод «n_tty_write», а затем передает буфер функции «output_process_block», которая, удостоверившись, что мы ввели не символ позиционирования каретки, просит «tty_struct» позвать «tty_driver». Всё верно, мы переходим на III уровень.
«Tty_struct» успешно играет роль посредника, и вот – уже запускается метод «con_write» tty-драйвера по имени «console_driver». Драйвер III-его уровня рад бы выполнить своё дело, но он один, консолей много – с какой надо работать? На помощь опять приходит «tty_struct» и вручает драйверу нужный экземпляр структуры «vc» (она отвечает за состояние своей конкретной консоли и содержит её клавиатурные, экранные установки, а также набор методов графического отображения).
«Сonsole_driver» блокирует консоль и призывает «vc_data» выполнить наконец эхо символа. «Vc_data» с ужасом осознает: к ней обратились не ради вопроса о самочувствии вверенной ей консоли, а ради действия. Это значит лишь одно: пора звать на помощь методы «consw», которые в нашем случае представляет VGA (при другой конфигурации ядра это может быть, например, framebuffer). И точно – VGA споро берется за дело, скрывает курсор, печатает символ, при необходимости прокручивает экран или переходит на новую строку, перемещает и отображает курсор. «Vc» выдыхает: «console_driver» работу принял и консоль разблокировал. Можем выдохнуть и мы, ведь все три уровня успешно пройдены, каждый компонент свою миссию выполнил.
3. KEEP AN EYE ON VIRTUAL TERMINAL
Но это еще не всё: пришло время познакомиться с представителями еще одного класса обитателей /dev – c эмуляторами терминалов. Это те самые xterm или gnome-terminal, которые мы запускаем с консоли, оснащенной графической оболочкой, используя, например, Ctrl-Alt-T или Ctrl-Shift-T.
Живут они в отдельном вольере /dev/pts (=pseudo-terminal slave) и представляют собой файлы под номерами 0, 1, 2 и т.д. Выполняем ps в текущем терминале и видим – мы на /dev/pts/1. Нажимаем Alt+5 – перемещаемся на наш четвертый по порядку открытия терминал, файл виртуального устройства которого /dev/pts/20. На любом терминале нас встречает bash, с каждым терминалом связано своё множество процессов. Пока никаких сюрпризов.
Но заметим: /dev/pts/X создаются динамически, запускаются на одной консоли /dev/tty7, не требуют запуска login и самое интересное – здесь нет правила «кресла»: мы можем открыть несколько виртуальных терминалов и одновременно наблюдать, как происходит работа на каждом из них. В очередной раз у %username% может появиться повод для сомнений: сохраняется ли и здесь принцип tty-абстракции и как в этот принцип вписывается устройство — slave, которым, вероятно, управляет некое устройство — master?
Новый объект не заставляет себя ждать: в единственном экземпляре файл ptmx лежит в той же директории /dev (На самом деле он может быть и не один: если запущено более одной консоли с графической оболочкой). По ману, при открытии /dev/ptmx создается подчиненная часть псевдотерминала /dev/pts/X, связанного со своей ведущей частью «ptm» (обращение происходит через дескриптор файла, но реальный файл не создается). Затем «ptm» передается в функции grantpt и unlockpt, и после всего этого можно открывать непосредственно /dev/pts/X, который будет вести себя точно так же, как виртуальная консоль (за исключением описанных выше особенностей).
Для нас в ключе идеи tty-абстракции это означает следующее: когда пользователь хочет запустить эмулятор терминала, XServer обращается к /dev/ptmx с просьбой создать виртуальное устройство /dev/pts/X. Могущественный «мультиплексер» /dev/ptmx любезно делает это, закрепляет файл устройства за экземпляром терминала и … /dev/pts/X занимает место /dev/ttyX, ему назначается драйвер слоя TTY_LINE_DISCIPLINE, его ласково принимает в свои объятия TTY_DRIVER. Стек над /dev/pts/X принимает уже привычный вид. Задача изучения механизма эмулятора терминала плавно сводится к предыдущей истории с виртуальной консолью, однако его подробное изучение требует отдельной статьи (которая входит в планы на будущее!).
4. LET’S PLAY WITH TTY LINE DISCIPLINE
На секунду вспомним tty-«палеозой»: было время, когда слой TTY_LINE_DISCIPLINE и отдельным слоем-то не был и полноценной современной функциональностью не обладал. Попробуем оценить вес перемен, произошедших с тех пор.
Для начала убедимся, что мы действительно имеем дело с N_TTY:
Всё познается в сравнении, поэтому действуем кардинально и с помощью stty отключаем все полезные фичи N_TTY:
Результат наглядно демонстрирует область ответственности N_TTY, без которой вывод не форматируется, ввод не отображается. Причем, если мы откроем новый терминал, то убедимся в целостности и невредимости его LINE_DISCIPLINE. Полученный эффект наталкивает на мысль: мы точно знаем, какой компонент обрабатывает весь наш ввод, мы можем модифицировать его для каждого виртуального терминала в отдельности и, помнится, мы слышали, что этот компонент можно заменить, загрузив свой модуль.
К сожалению, N_TTY сама по себе является частью ядра. Поэтому за основу возьмем другие драйверы слоя LINE_DISCIPLINE, предусмотренные в Linux и загружаемые в виде модулей. По их образу и подобию модифицируем файл исходного кода n_tty.c:
Теперь добавим какой-нибудь функционал, отличающий нашу линию дисциплины от оригинальной. Помним, что именно TTY_LINE_DISCIPLINE обрабатывает служебные последовательности, поэтому грех не поколдовать на этом поприще. Для этого открываем функцию «n_tty_receive_char_special», в которой TTY_LINE_DISCIPLINE проверяет, не является ли введенные символы специальными и при нахождении оных посылает соответствующий сигнал. Для примера поменяем местами сигналы, генерирующиеся для Ctrl+Z и Ctrl+С:
После этого получим из нашего модифицированного файла непосредственно модуль ядра our_ldisc.ko. Загрузим его, убедимся, что загрузка произошла успешно. Проверим, что «our_modyfied_ldisc» действительно зарегистрировалась как TTY_LINE_DISCIPLINE. Откроем терминал и посмотрим номер pts. После этого назначим наш драйвер ответственным за слой TTY_LINE_DISCIPLINE у /dev/pts/X:
Настроим новую линию дисциплины с помощью команды «stty echo cooked» — теперь терминал работает в привычном для нас режиме. Запустим тестовую программу с вечным циклом и сравним эффект Ctrl+Z и Ctrl+С:
Мы добились желаемого: генерация сигналов переопределена на уровне драйвера слоя TTY_LINE_DISCIPLINE в индивидуальном порядке для одного эмулятора терминала! Есть поле для работы фантазии: от фокусов с обработкой служебных последовательностей до кастомизированного фильтра команд.
В ЗАКЛЮЧЕНИЕ
Теперь для тебя, %username%, тайны виртуальных консолей и эмуляторов терминала – больше не тайны, беспорядочная магия – не магия, а технология, прошедшая немалый путь, чтоб создать гибкую подсистему tty, а телетайп – не артефакт древности, а изобретение (кстати говоря, наше, отечественное), без потомков которого современный компьютер представлять как-то не хочется.
Мы любим рассказывать увлекательные истории. Хочешь послушать их вживую? Приходи на «Очную ставку» NeoQUEST-2017, там тебя ждёт множество интересных докладов: от «железа» до криптографии! Вход свободный при регистрации на сайте.