LinuxCamp | DevOps

Компоновка с динамическими библиотеками Перед применением библиотеки необходимо выполнить 2 дополнительных шага, которые не требуются для работы со статическими аналогами: 1. Поскольку исполняемый файл не содержит копии необходимых объектных модулей, он должен иметь возможность определять, какая разделяемая библиотека требуется для работы. Для этого, на этапе статической компоновки, в ELF файл программы внедряется метка DT_NEEDED с именем библиотеки. Если говорить чуть более точно, то в поле DT_NEEDED записывается полный путь до библиотеки. Если зависимость находится в неизвестном компоновщику каталоге, то лучше указать дорогу через флаг -L, иначе потом может возникнуть вопрос "Почему зависимость находится корректно при ее локальном размещении?" - потому что ее полый путь записан в поле NEEDED.

$ gcc -Wall -o prog main.o -L=./libs/ -ldemo

// Выводим содержимое динамической секции ELF файла
$ readelf -d ./prog
    
Dynamic section at offset 0xd88 contains 28 entries:
   Tag        Type                         Name/Value
    0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
    0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

2. Должен существовать механизм, который, во время выполнения программы, находит библиотеку по имени и выгружает ее в память, если она не была загружена ранее. Данная процедура выполняется динамическим компоновщиком и необходима для разрешения имени библиотеки на этапе выполнения. Компоновщик, сам по себе, является разделяемой библиотекой “/lib/ld-linux.so.2” и используется всеми исполняемыми файлами формата ELF, которые содержат динамические зависимости. На самом деле, Id-linux.so.2 представляет собой обычную символическую ссылку на библиотеку динамического компоновщика “Id-<version>.so” (например, ld-2.11. so), где version - это версия glibc, которая установлена в системе. Если на данном этапе попробовать запустить программу, выведется следующее сообщение об ошибке:

$ ./prog

./prog: error in loading shared libraries: libdemo.so: 
    cannot open shared object file: No such file or directory

Это возвращает нас ко второму пункту. Дело в том, что динамический компоновщик анализирует список рантайм зависимостей программы и находит соответствующие библиотечные файлы, используя набор заранее заданных правил. Часть этих правил основывается на списке стандартных каталогов, в которых обычно хранятся разделяемые библиотеки (lib и /usr/lib). Причина ошибки выше заключается в том, что библиотека находится в текущем каталоге, который не учитывается при поиске. Для оповещения динамического компоновщика о том, что разделяемая библиотека находится в нестандартном месте, можно воспользоваться переменной среды LD_LIBRARY_PATH, указав соответствующий каталог в качестве значения. Если переменная определена, компоновщик начинает поиск разделяемой библиотеки с тех каталогов, которые в ней перечислены, и только потом переходит к стандартным библиотечным путям. Следовательно, можно запустить программу с помощью следующей команды:

$ LD_LIBRARY_PATH=./libs ./prog

Динамические библиотеки Для устранения недочетов статических библиотек были придуманы динамические (разделяемые). Их ключевая идея состоит в том, что объектные модули не копируются в исполняемый файл: вместо этого единый экземпляр библиотеки загружается в память при запуске первой, от нее зависящей, программы. Если позже будут запущены другие приложения, которым нужна эта библиотека, они обратятся к уже загруженной копии. В результате такой концепции исполняемые файлы требуют меньше места на диске и в виртуальной памяти. Разделяемые библиотеки обладают следующими преимуществами: 1. Общий размер программ уменьшается, в связи с чем они могут быстрее загружаться в память и, как следствие, запускаться. Это относится только к большим разделяемым библиотекам, которые уже используются другими процессами. На самом деле, программа, которая первой начинает использовать библиотеку, запускается дольше остальных, т.к. с ее инициализацией происходит поиск библиотеки и выгрузка ее в память. 2. Объектные модули не копируются в исполняемые файлы, поэтому можно изменять исходный код библиотеки без необходимости выполнения повторной компоновки. Полностью осознать данное преимущество поможет вымышленный пример, где стандартная библиотека C (libc) является статической. Если кто-нибудь найдёт и исправит баг в printf, то каждая программа должна будет заново пройти компоновку для того, чтобы заполучить исправленный код. Использование динамических библиотек действительно полезно в случае, когда они являются необходимыми для большинства программ и имеют внушительный размер (QT/GTK). Однако за эти дополнительные возможности приходится платить: 1. Динамические библиотеки более сложные по сравнению со статическими - как с точки зрения самой концепции, так и в плане создания и компоновки внутри программ. 2. Излишняя зависимость: если в библиотеку было внесено изменение, нарушающее ее совместимость с приложением, запуск будет невозможен. Со статически собранным вариантом такой проблемы не наблюдается, т.к. в нем все необходимые объектные файлы хранятся в виде копий. 3. Перемещение символов должно выполняться во время работы программы: этот процесс требует дополнительных работ, в том числе, выгрузки ядром разделяемой библиотеки динамического линковщика ld-linux.so для связывания на этапе выполнения. Все это приводит к затратам по времени, поэтому программа может работать немного медленнее статически скомпонованного аналога. Для сборки динамической версии библиотеки необходимо выполнить:

/* -Wall - выводит предупреждения, вызванные потенциальными ошибками в коде, не препятствующими компиляции программы, но способными привести, по мнению компилятора, к тем или иным проблемам на этапе выполнения. */

// -fPIC - завставляет компилятор сгенерировать адресно-независимый код.
$ gcc -c -fPIC -Wall module1.c module2.c module3.c

/* -shared - указывает gcc, что в результате должен быть собран не исполняемый файл, а разделяемый объект - динамическая библиотека. */
$ gcc -shared -o libdemo.so module1.o module2.o module3.o

Разбор пакетов: build-essential Метапакет в Linux, который включает в себя все основные зависимости и инструменты, необходимые для создания debian сборок из исходного кода. Пакет является Debian-специфичным, поэтому отсутствует в репозиториях для Fedora/RedHat/CentOS и т.д. Сам по себе не является программой, он всего лишь содержит список зависимостей, которые менеджер apt считывает и устанавливает в систему. Так как готовый пакет может включать бинарь программы, build-essential ставит соответствующие инструменты для компиляции и компоновки. Главное - не считать его супер решением, которое магическим образом установит все необходимое рабочее окружение для Ruby, Go, Python и т.д. В первую очередь, пакет содержит список базовых инструментов для сборки (.deb) образов. Некоторыми компонентами являются: 1. gcc/g++: стандартные C/C++ компиляторы в среде разработки Linux. 2. libc6-dev: заголовочные и объектные файлы, необходимые для сборки приложений, использующих стандартную библиотеку C. 3. util-linux: различные утилиты командной строки (chroot, fdisk, mount). 4. dpkg-dev: инструменты, необходимые для создания и управления пакетами в формате (.deb). 5. make: универсальный инструмент для автоматизации сборки программ.

sudo apt install build-essential

Версионирование разделяемых библиотек: Как известно, одним из преимуществ разделяемых библиотек является отсутствие необходимости в повторной компоновке исполняемых файлов, которые библиотеку используют: программа во время выполнения подтягивает необходимые ее части и не содержит копий объектных файлов, как в случае со статическими аналогами. В Linux у вас может быть несколько версий одной и той же библиотеки. Следование правилам версионирования и компановки позволяет сохранить работоспособность программ при обновлениях, которые нарушают совместимость (добавление дополнительного параметра в публичный метод: подробнее можно ознакомиться здесь). Корректно спроектированная динамическая библиотека должна состоять из 3 имен: 1. Реальное имя - название самой библиотеки “lib<name>.so.<major>.<minor>.<patch>”. Напрямую при линковке не используется (разве что для дебага). Major - меняется в случае, когда правки приводят к несовместимости с приложениями (изменение API). Minor - меняется при расширении API (добавлении функционала). Patch - багфиксы, оптимизации (изменение функционала внутри готового API). 2. SONAME - метка, которая записывается в файл библиотеки на этапе создания (DT_SONAME в терминологии формата ELF). Именно она встраивается статическим компоновщиком в программу и, как следствие, используется динамическим компоновщиком для поиска на этапе выполнения. Структура, обычно, следующая “lib<library name>.so.<major>”.

/* Создаем libdemo.so.1.0.0 с меткой libdemo.so.1 */
$ gcc -shared -Wl,-soname=libdemo.so.1 -o libdemo.so.1.0.0 module1.o

3. Компоновочное имя - используется на этапе статического связывания приложения и библиотеки (не содержит номеров версий).

/* В исполняемый файл prog будет записан soname, к которому приведет нас libdemo.so */
$ gcc -g -Wall -o prog main.o libdemo.so

Для того, чтобы корректно подключить зависимость, нужно создать 2 символьные ссылки: 1) связывает компоновочное имя и soname; 2) связывает soname и реальное имя библиотеки; Компоновочное имя может указывать на файл библиотеки, но желательно, чтобы оно ссылалось на soname, т.к. пользователь может удалить старую версию после минорного обновления и ссылка станет невалидной.

libdemo.so -> libdemo.so.1
libdemo.so.1 -> libdemo.so.1.0.0
libdemo.so.1.0.0

После корректного обновления библиотеки, ссылка soname должна указывать на самую последнюю ее версию, в результате чего, ваше приложение будет работать с актуальным экземпляром.

libdemo.so.1 -> libdemo.so.1.0.1

Если обновление меняет мажорную версию, то, при использовании утилиты ldconfig, автоматически будет создана ссылка, связывающая soname и имя библиотеки. При этом, приложение будет работать с последней совместимой версией (если не была удалена).

$ sudo ldconfig -v | grep libdemo
libdemo.so.2 -> libdemo.so.2.0.0 (changed)

/* Выводим диинамические зависимости программы */
$ ldd prog
libdemo.so.1 => ./libdemo.so.1 (0x0000ffff8f870000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff7ff50000)

Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией. Ядро 0.0.1 имело размер 62 Кб в сжатом виде и содержало около 10 тысяч строк исходного кода. Кодовая база последних версий насчитывает более 30 млн строк. По данным исследования, проведённого в 2010 году по заказу Евросоюза, приблизительная стоимость разработки с нуля проекта, аналогичного современному ядру Linux, составила бы более миллиарда долларов США. Динамика роста кодовой базы ядра Linux: 0.0.1 - сентябрь 1991, 10 тыс. строк; 1.0.0 - март 1994, 176 тыс. строк; 1.2.0 - март 1995, 311 тыс. строк; 2.0.0 - июнь 1996, 778 тыс. строк; 2.2.0 - январь 1999, 1.8 млн. строк; 2.4.0 - январь 2001, 3.4 млн. строк; 2.6.0 - декабрь 2003, 5.9 млн. строк; 2.6.28 - декабрь 2008, 10.2 млн. строк; 2.6.35 - август 2010, 13.4 млн. строк; 3.0 - август 2011, 14.6 млн. строк. 3.5 - июль 2012, 15.5 млн. строк. 3.10 - июль 2013, 15.8 млн. строк; 3.16 - август 2014, 17.5 млн. строк; 4.1 - июнь 2015, 19.5 млн. строк; 4.7 - июль 2016, 21.7 млн. строк; 4.12 - июль 2017, 24.1 млн. строк; 4.18 - август 2018, 25.3 млн. строк; 5.2 - июль 2019, 26.55 млн. строк; 5.8 - август 2020, 28.4 млн. строк; 5.13 - июнь 2021, 29.2 млн. строк; 5.19 - август 2022, 30.5 млн. строк;

Утилиты командной строки: top и htop Команды необходимы для мониторинга производительности системы (Linux). Их использование полезно для анализа процессов и определения того, сколько CPU тратится на их выполнение, какое потребление оперативной памяти и т.д. До знакомства с более продвинутыми средствами профилирования, сам использовал htop для обнаружения утечек памяти и узких мест программы, где потребление CPU зашкаливало 🔥 Их основные отличия: Доступность • top: Является предустановленным для болишинства UNIX систем. • htop: Требует ручной установки (доступен в большинстве стандартных репозиториев). Интерфейс • top: Текстовый интерфейс с ограниченными возможностями навигации. • htop: Интерактивный интерфейс с возможностью использования мыши, прокрутки и сортировки. Информация о системе • top: Отображает основную информацию о системе - использование ЦП, памяти, своп и процессов. • htop: Предоставляет более подробную информацию, включая использование диска, сетевой трафик, температуру ЦП, использование его ядер и многое другое. Управление процессами • top: Позволяет убивать процессы, изменять их приоритет и просматривать подробную информацию. • htop: Предлагает более расширенные возможности управления процессами, такие как древовидный вид, фильтрация и поиск. Настраиваемость • top: Имеет ограниченные возможности настройки. • htop: Высоко настраиваемый, позволяет изменять цвета, столбцы и горячие клавиши. Другие функции • top: Может отображать графики использования ресурсов. • htop: Имеет встроенный просмотрщик файлов, монитор сети и другие полезные функции. Ресурсоемкость • top: Более легкий и потребляет меньше ресурсов. • htop: Более ресурсоемкий, но предлагает расширенный набор функций. Бонус, если вы все еще используете top: для того, чтобы преобразить его внешний вид и вывести дополнительную информацию, можно воспользоваться последовательным вводом (1, z, c, m) 👨‍💻

Pluggable Authentication Modules (PAM) 🔒 Как-то в статье про окружение рабочего стола я разбирал компонент, который использует PAM для аутинтификации пользователя в системе, имя ему "Дисплейный менеджер". Данная система представляет собой набор библиотек и конфигурационных файлов, с помощью которых стороннее приложение получает возможность авторизовать пользователя.  Существуют библиотеки PAM, позволяющие выполнять аутентификацию через: локальные пароли, LDAP или считыватели отпечатков пальцев 👍 Как было раньше: желая войти в систему, пользователь был вынужден пообщаться с программой-охранником, гордо именуемой login. Она спрашивала имя, затем шифровала пароль известным алгоритмом и сверяла получивуюся абракадабру с записью в файле /etc/passwd. Если все совпадало, то вход в систему был разрешен. Через некоторое время, наученные горьким опытом, системы перестали хранить зашифрованные пароли в файле /etc/passwd, открытом на всеобщее обозрение, и переместили эту интимную информацию в файл /etc/shadow, читать который дозволено было только обладателям прав суперпользователя. Программа login была переписана заново: теперь она умела читать из нового файла и шифровать данные по более серьезному алгоритму. Неизвестно, сколько еще раз пришлось бы переписывать эту программу, если бы не пришла кому-то в голову мысль вынести механизм аутентификации в отдельную систему. Данная разработка получила название PAM. Теперь, если программа жалает произвести аутентификацию пользователя, она не делает этого самостоятельно, а обращается к PAM с соответствующей просьбой. Последний выполняет все проверки и докладывает о результатах - пускать или нет.

Статические библиотеки ❗️ Статические библиотеки были первым видом библиотечных файлов, доступных в UNIX системах. Они позволяют объединить набор часто используемых объектных файлов и использовать их для сборки различных программ ⚙️ Статическая библиотека, по сути, является обычным файлом, содержащим копии всех, помещенных в него, объектных файлов. В библиотеке также хранятся атрибуты для каждого объекта: права доступа, время последнего изменения, идентификаторы пользователя и группы. Статическая библиотека может состоять из множества объектных модулей, но не все они будут включены в итоговую программу - компоновщик выберет только те, которые необходимы. Таким образом, программа, скомпонованная со статической библиотекой, содержит копии всех объектных модулей, которые были включены в нее компоновщиком, что может приводить к избыточности и ряду неудобств 🥸

Торвальдс посоветовал Кису Куку (Kees Cook) из Google быть решением, а не проблемой в работе с кодом и мейнтейнерами ядра Linux + перестать плодить неразумные жалобы на код компилятора. Кук вместе с другими экспертами Google работает над выяснением того, как лучше справляться с неожиданными ошибками арифметического переполнения в исходном коде C ядра Linux. ✖️ Он надеется увидеть систематический способ, позволяющий ядру Linux справляться с такими арифметическими проблемами переполнения/недополнения/зацикливания. ⌛️ Среди первоначальных идей — лучше использовать санитайзеры на основе компилятора или возможности языка C для перегрузки операторов без искажения имён.

Valve продолжает радовать своей вовлеченностью 📱 Не секрет, что компания вкладывает много ресурсов в развитие open-source проектов. Конечно, им нужно, чтобы SteamOS работала как часы с окружением kde-plasma и различными железками. Новость говорит о том, что начали они вносить свои правки в NVK (открытый драйвер NVIDIA, который входит в состав Mesa) для лучшей поддержки функционала вулкана. Что особенно интересно - Valve начал активно работать над поддержкой NVIDIA. Никто не забыл, что SteamDeck работает на AMD и сам SteamOS рекомендован к запуску на графике этого производителя? Такая инициатива может намекать на целевое движение SteamOS в сторону большого рынка 🔤

Сможет ли дека вывести линукс в массы❓ Пока ситуация какая: линукс широко распространен среди разработчиков. Для многих обывателей это все еще непонятная история. К такому развитию событий ведет ряд причин: отсутствие необходимого софта, проблемы с его установкой и запуском, много работы с терминалом, отсутствие единого для всех решения (миллион дистрибутивов, какой ставить...). Пока эти проблемы существуют, у пользователей других ОС не будет особой мотивации что-то менять. Появление SteamDeck показало, что Valve не особо хочет подвязываться к Windows - в идеале, должна быть абсолютно открытая и дицентрализованная ОС, на которой можно будет спокойно запускать игры и не переживать о том, что Microsoft что-нибудь придумают и пользователи спустятся на уровень xbox и playstation. В общем, сейчас доходы Valve немало зависят от имиджовой работы Microsoft. Компания постепенно будет пушить создание нативных Linux портов и разработку драйверов для лучшей поддержки игровой периферии и последних нововведений железа. Как результат: Nvidia начала активнее обновлять драйвера + появилась поддержка некоторых античит систем. Результат папуляризации виден уже сегодня, но для лучшего эффекта Valve следует: 1. Сделать их ОС полноценно подходящей для десктоп задач (расширить список flatpak приложений, доработать kde-plasma, добавить больше пользовательского софта) 2. Доработать поддержку старого/нового железа 3. Зафорсить игровые компании выпускать ноутбуки/пк со SteamOS на борту В общем, перспективы есть, нужно работать 👨‍💻

В продолжении разбора файловой системы, рассмотрим ссылки 🔗 Ссылки бывают 2 типов: жесткие, символические Жесткие: имеют ID, равный элементу, на который ссылаются. Это означает то, что один и тот же файл (структура inodes) может иметь несколько имен 🖖 Не содержат отдельного поля в таблице индексных дескрипторов -> при создании жесткой ссылки, счетчик ссылок для файла увеличивается 🔼 При удалении изначального файла или ссылки, значение счетчика уменьшается, но блок с данными файла остается нетронутым до тех пор, пока существует запись в таблице🔽 Когда счетчик ссылок = 0, запись в таблице исчезает -> данные для файла затираются 🤪 Хммм, а можно создать жесткую ссылку на каталог? 🤔 Нет! Это предотвращает цикличную зависимость в файловой системе 🚫 Символичесие: являются отдельным типом файла, данные которого - имя другого файла 👉 При создании ссылки, счетчик для файла останется неизменным 🔄 Следовательно, если удалить имя файла (изменить путь), с которым соотносится ссылка, сама она останется, несмотря на то, что ее нельзя будет разыменовать 🔒

В файловой системе все 🚩 Две особенности отличают директории от обычных файлов: 1. Для каталога указывается другой тип файла в записи индексного дескриптора ✉️ 2. Блок данных, на который указывает соответствующее поле в таблице inodes, содержит названия файлов/директорий и индексы, по которым происходит поиск элементов в таблице 🔍 Если блок с данными файла содержит внутреннюю его информацию, то блок с данными директории, по сути, является таблицей с полями “имя дочернего элемента / id" в таблице индексного дескриптора 🔗 Ремарка для программистов: Несмотря на то, что процесс может открыть каталог, он не может применять системные вызовы read и write для того, чтобы изменить данные по дескриптору 🔒

Habr: Все про композитинг в X11 | Linux 🐧 1. Разбор графического стека Linux 2. Разбор графического стека Linux (рус) 2. Статья про композитинг 3. Статья про композитинг 4. Как обработать и сохранить графическое представоение окна после перенаправления? 5. Статья про композитинг, автором которой является разработчик kwin 6. Статья про композитинг 7. Исходный код awesomewn (ссылается на файл, который контролирует root и его фон) 8. Описание функционала различных компонентов рендера X11 (Drawable, Pixmap, Image, Visual) 9. Что из себя представляет фон рабочего стола + как его выставить и получить? 10. Программная реализация небольшой кодовой базы, на которой основывается композитинг 11. Для чего нужны DDX драйвера, когда Xorg использует DRM? 12. Документация расширения XComposite 13. Как X11 использует графическое ускорение? 14. Книга про разработку графики, неплохо растолковывает то, как устроена оконная система X 15. Что такое DRI? 16. Что такое DRM? 17. Что такое framebuffer? 18. Что такое двойная буферизация? 19. Что такое EGL/GLX? 20. Что такое OpenGL контекст?

Кто что слышал про Nobara Linux? ❓ Очень интересная сборка, которая как бы должна давать в лоб всем хейтерам “домашнего” Linux, но пока этого сделать не может из-за немалого количества багов. ⚙️ Дистрибутив разработан создателем Proton GE - пропатченной и доработанной версии утилиты Proton для запуска steam игр на линухе. 🎮 Nobara предоставляет широкий спектр приложений (в том числе, с кастомными патчами), зависимостей и драйверов “из коробки”. 🛠 Хорошо подходит для геймеров и фото/видео монтажеров, т.к. весь необходимый софт довольно просто ставится и, в некоторых случаях, может показать лучшую производительность 📱 Достаточно неплохо вас может познакомить с этим дистр вот это видео

Если бы меня спросили “Какую книгу стоит прочесть для того, чтобы приблизиться к абсолютному пониманию Linux?”, ответ был бы однозначным: “Linux API Исчерпывающее руководство” - Майкл Керриск 📕 Книга не только знакомит читателя с различными подсистемами операционки, но и глубоко их разбирает, приводит примеры реализации различных модулей на языке C (нативном для ядра и множества системных программ) 👨‍💻 Материал очень грамотно подается: все начинается с подробного разжевывания базовых терминов (kernel, linux, unix, posix, gnu) и уходит вплоть до реализации TCP протокола и файловой системы 😶 Хардкорные сишники/плюсовики (бэкендеры) точно оценят книгу, т.к довольно глубоко объясняются принципы сетевого взаимодействия на сокетах и мультиплексирование ввода/вывода (poll, epoll, select) 🤘

Ссылаясь на регионы, вот так получилось оптимизировать композитинг без использования OpenGL для проверки глубины 😮 На самом деле, все пространство за окном забито иконками => потребление GPU кратно сокращается, когда мы убираем их из рендера. Тут прозрачность для демонстрации, а так, конечно, рендерить не нужно только в случае, если не видно 🙈

Habr: Компоненты среды рабочего стола | Linux 🐧 1. Принцип работы PAM системы аутентификации 2. Туториал по созданию дисплей менеджера 3. Исходный код дисплей менеджера SDDM 4. Исходный код DM с исключительно базовым функционалом 5. Принцип коммуникации X11 клиента и оконного менеджера 6. Исходный код стартап модулей окружения kde-plasma (startkde) 7. Как dm понимает, какое окружение запустить? 8. Исходный код оконного менеджера dwm 9. Как работают оконные менеджеры в X11 и как написать такой? 10. Что такое оконный менеджер? 11. Что такое gnome-shell? 12. Общая информация про оконные менеджеры

Интересная статья на тему регионов 🤖 Недавно проработал алгоритм, который исключает из рендера окна, которые перекрыты и не видны пользователю - что-то вроде теста глубины, только на CPU. 🤫 Можно будет сделать урок с подробным разъяснением математики регионов и реальными примерами использования 👀