Ядро
Странная тема -- ядро.
О прикладной части, которая активно втягивается нынче в систему, и про собственно ядро -- управление ресурсами, которыми пользователь пользуется опосредованно через два хопа -- сначала он вызывает библиотечную функцию, та зовёт ядерный вызов, а вызов ходит к ресурсу.
Какое главное требование пользователя к ядру ОС. Что может захотеть от него пользователь? Его не замечать. Этот идеал достижим только на устройствах, где никогда не является аппаратная составляющая. Первое, что надо вспомнить, говоря о ядре и модулях (рис. цветочек) -- что модули работают, также как ядро в режиме супервизора, но в отличие от него могут подгружаться и выгружаться. Причем это linux-utils. В том смысле вот вам и то, что пользователь может захотеть от ядра -- подгрузить или отгрузить модуль. lsmod, insmod, rmmod. Они низкоуровневые, пользоваться с осторожностью.
Модулей подгружено в систему много, как очевидные типа дисковой подсистемы, так и эзотерика, например, crc16. Встает вопрос -- а откуда они там взялись, когда вы их руками не загружали. Плохой ответ -- так сложилась эволюция.
Ещё одна утилита modinfo. Лучше запускать из под суперпользователя, которая расскажет интересную информацию о модуле -- файл из которого он загружен, лицензию, дополнительные флажки. И, что важно, довольно позновательную строчку vermagic, которая имеет отношение к версии и к магии. Это способ, чтоб ядро не подгружало не свои модули. Была революция в процессе сборки ядра -- каждый модуль получает строчку с информацией, для какого ядра под какую архитектуру проводилась сборка. Достаточно хороший инструмент явно не дать ядру загрузить чужой модуль, который модет с ним быть несовместим. Попытка описать совместимость более сложными правилами обычно не работает. А вермэджик-- простая строка. Инсмод оперирует с файлами (вопрос из зала)
ППользователь, даже если он суперпользщователь обычно руками не зовет инсмод и рммод, потому что:
- когда вы загружаете модуль инсмодом нужно указать путь до модуля, который может быть нетривиально синтуичить. Существует программа depmod, которая строит карту расположения модулей и строит файл с номерами производителя железа. Помимо этого модуль ядра может содержать привязку к конкретному железу, что облегчает его автоматическую подгрузку при появлении оного железа в системе. Депмод строит такую табличку, для какого конкретного пси этот модуль написан. Полученная табличка может быть обрабботана без всяких путей к файлам, а просто по именам модулей, командой modprobe. он понимает алиасы и всякое такое. Именно модпробом обычно загружают и выгружают модули. Это вопрос, к которому мы ещё вернёмся -- модуль грузится с параметрами. Некоторые параметры нельзя менять не выгружая модуля.
- Помимо этого есть ещё одно свойство у модпроба -- если мы загружаем модуль звуковой карты, он подгрузит звуковую подсистему. Зависимость модулей. Какой нибудь усб сторадж тянет за собой целую пачку устройств -- генерики, хабы, итд. Инсмодом замучаетесь, а модпроб сам.
- Есть в каталоге /sys (вирт фс, отвечающая аппаратной составляющей компьютера) есть module в котором лежат фйлы и каталоги с информацией о модулях. Ещё один пример как с помощью вирт фс инф не являющаюся текстовым файлом превратили в текстовый файл. Там есть и параметры modinfo. Core-size, ref counter итд. Вот это место для лиукс систем прямой объект интереса, если вы пишите какой-то скрипт работающий с модулями.
У модпроба 2 старницы ключиков, в частности с модпробом можно насильчтвенно загрузить модуль с другим вермэджиком. Если соотв модуль бинарный и несвободный длрайвер.
Модули лежат /lib/modules/<версия>
На одном компьютере модет быть установлено несколько ядекр и они не будут мешать друг другу. Это часто эксплуатируется. Обычная практика для лектора -- всегда иметь 2 ядра. Первым делом при обновлении на нвого ядро удаляются все старые кроме последнего. Если при установке нового дяра все перестало работать, загружается старое. Почему в приницпе эта вещя важная -- потому что ядра очень много занимают, сотни мегабайт каждое. Во вторых модеет случиться такая вещь, что когда вы используете на стабильном репозитории, то ничего менять и не надо. Или надо но только при покупке новых девайсов. Купили вайфай свисток, а он не свистит. Посмотрели -- свисток будет только в последнем ядре, его и ставите.
Что может сопровождать обновление ядра -- возможны некоторые революции. Вполне может быть такая штука, что удев немножко поменялся, и что то перестанет работать. Буквально на днях выловили забавную багу в 3.3.1. Есть такой системный выхов set login uid -- доставлять процессу уид залогиненного пользователя. Штука довольно неожиданная. У процессов которые стартуют при старте системы, оно -1. А когда вы рестартите сервис руками, он становится 0. В 3.3.1 запретили менять логин уид. Говоришь ссхд рестарт и больше залогиниться ты не можешь. Связано это с заменой инита системд. В отличиеинита системд всегда стартует сервисы своей специальной стартовалкой, и с ней все работает. Про системд будем упоминать на след версии.
Если у вас болезнь новых версий, готовьтесь к тому, что новые ядра могут не работать и некоторое количество старых надо иметь в запасе.
Откуда беруться модкли?
- ядро. ядро собирается с несчетным количеством модулей сразу
- драйверы железяк и соотв пакетов илибинарных блобов.
- сборка своими руками. Здесь может вот какое соображеие помочь -- корпорация кривулька лимитед не просто написала драйвер замечатльной кривуьки, но и написала для опр ядра опр версии и вставила туда проверки для нормальной сббборки. Но не пропихивает никуда в апстрим и несвободной лицензии. Текст есть, а распространять нельзя. Так делала делл.
Метод в следующем -- сделть набор не очень грязных хаков, которые будут позволять пересобирать модуль ядра при каждом обновлении ядра. Называется dkms. Это всем лучше, чем подгружать бинарный модуль с отключенным вермэджиком.
Загрузка сейфмод -- ядру насовывают некоторое количество параметров загрузки, отключающие некритичные для жизни ситемы.
Это никак не гвоорит о том, откуда модули взялись при старте ядра. Частично они были подгружены при старте инишиал рам диска. Мы помним что это такой типично линуксовый подход к решению проблемы курицы и яйца.
При появлении железяки которой надо засовывать фирмваре, запуском засовывателя занимается удев. Андроид ломался -- ему подсовывали удевное правило запускать шелл с правами рута когда что-нибудь произойдет. Он модет реагировать не только на появление новой железяки.
Перед тем, как будет раотать удев, который запихивает и подгружает модули согласно некоторым павилам в онлайне, перед этим при старте модпроб, аточнее модутилз подгружает или не подгружает модули прям по списку. В каталоге етц все файловые объекты, начинающиеся с mod, вы найдёте кучу конфигов. Это правила загрузки модулей при старте системы. В большинстве своем это черные списки -- при наличии какого железа все равно не грузить его модуль. Если есть два драйвера в системе, один работающий один нет, то нет будет прописан там.
Когад в линуксе стали делать поддержку ипв6, её поддеркжа попала в либсдл -- библиотечки для написания двумерных игр. Любая программа написанная на сдл пыталась ходить на :1:1, и подвисала.
/etc/mod* -- всё файлы, которые этим управляют.
На самом деле разговор шел про предыдущую чатсь -- удев. В частности он отдает при заведении девайса его в собственность такой то группе, ну и много чего делать.
В альте есть два катлога с которыми приезжает удев -- это /etc/udev/rules.d -- туда распихивают правила службы и драйверы не относящщеся к самому удеву. И есть /lib/udev/rules.d . В етц мождет быть файл, который определяет как у нас называются сетевые карты, когда их несколько. Когда-то при старте с несколькими стевыми картами порядок названий менялся. Почему такая глупость? Потому что удев заводить устройства при старте ситемы. От какой первым приходилло, ту он нулеевой заводил. Тоже самое с жестикми дисками.
Удев ставится с довольно таким приличным количеством вспомогательных утилит.
Возможна такая ситуация, что у вас появилась железяка, которая вообще не распознается. Тут есть два пути -- добыть соотв драйвер.. Путь второй -- попытаться заставить имеющийся драйвер считать что он годится для данного устройства.
kernel-parameters.txt -- всё что можно делать со всеми живыми модулями при их загрузке. quirk у usb-modules.
Если ваша задача попробовать затолкать некую железяку, с преположением что она работает с неким модулем, то кернел параметерс вам в руки.
Не забудем содержимое кактлога /proc, в котором много информации ии о нашем ядре.
Последнее, что осталось на сегодня рассказать это magic keys.
Для отладочных целей в ядро втиснуты специальные клавиши.
Alt-SysRq - что нибудь. На них лучше не нажимать, если не знаете что хотите. А то могу, например, полезть скан коды вместо букв в терминал.
Сравнительно безопасная перезагрузка
Alt-Sysrq-R -- release
Alt-Sysrq-S -- затолкать все грязные буфера на диск.
Alt-Sysrq-U -- анмаунт и маунт в ридонли.
Alt-Sysrq-B -- ребут
Alt-Sysrq-E -- терминейт все таски
Alt-Sysrq-I -- убить все таски
Сисрк тригер -- специальный файл, куда можно записать эти файлы эхом.
sysctl -- дикое количество парметров ядра, которое можно посмотреть, а иногда и поменять в процессе работы системы.