Ядро Linux

Ядро Linux

Тукс , талисман Linux Пингвин
Загрузка ядра Linux 3.0.0
Оригинальный автор(ы)	Линус Торвальдс
Разработчик(и)	Участники сообщества Линус Торвальдс
Первоначальный выпуск	0,02 (5 октября 1991 ( 1991-10-05 ) )
Стабильная версия	6.10.3   / 3 августа 2024 г.
Предварительный выпуск	6.11-rc2   / 4 августа 2024 г.
Репозиторий	мерзавец .ядро .org /паб /скм /линукс /ядро / git / Торвальдс /линукс .git
Написано в	C ( C11 начиная с 5.18, C89 ранее), Ржавчина (начиная с версии 6.1), Язык ассемблера
Доступно в	Английский
Лицензия	Только GPL-2.0 с примечанием к системному вызову Linux
Веб-сайт	ядро .org

Ядро Linux является бесплатным и открытым исходным кодом . UNIX-подобное ядро , которое используется во многих компьютерных системах по всему миру. Ядро было создано Линусом Торвальдсом в 1991 году и вскоре было принято в качестве ядра для (ОС) GNU операционной системы , которая была создана в качестве бесплатной замены Unix . С конца 1990-х годов он был включен во многие дистрибутивы операционных систем , многие из которых называются Linux . Одной из таких операционных систем с ядром Linux является Android , который используется во многих мобильных и встраиваемых устройствах.

Большая часть кода ядра написана на языке C, который поддерживается коллекцией компиляторов GNU (GCC), которая имеет расширения, выходящие за рамки стандартного C. Код также содержит ассемблерный код для логики, зависящей от архитектуры, такой как оптимизация использования памяти и выполнения задач. Ядро имеет модульную конструкцию, позволяющую интегрировать модули как программные компоненты , в том числе динамически загружаемые. Ядро является монолитным в архитектурном смысле, поскольку вся ОС работает в пространстве ядра .

Linux предоставляется по лицензии GNU General Public License версии 2 , хотя он содержит файлы под другими совместимыми лицензиями .

История

См. также: История Linux и история версий ядра Linux.

Линус Торвальдс на LinuxCon Europe 2014 в Дюссельдорфе

В апреле 1991 года Линус Торвальдс, 21-летний -компьютерщик студент Хельсинкского университета , начал работать над операционной системой, вдохновленной UNIX, для персонального компьютера. Начал он с переключателя задач на языке ассемблера Intel 80386 и драйвера терминала . 25 августа 1991 года Торвальдс опубликовал следующее в comp.os.minix группе новостей в Usenet :

Я делаю (бесплатную) операционную систему (просто хобби, не будет большой и профессиональной, как GNU) для 386(486) AT клонов . Это назревало с апреля и начинает готовиться. Я хотел бы получить любые отзывы о том, что людям нравится/не нравится в minix, поскольку моя ОС чем-то напоминает ее (среди прочего, такое же физическое расположение файловой системы (по практическим соображениям)).
В настоящее время я портировал bash (1.08) и gcc (1.40), и, похоже, все работает. Это означает, что через несколько месяцев я получу что-то практическое [...]
Да, он не содержит какого-либо кода minix и имеет многопоточную файловую систему. Он НЕ является переносимым [ sic ] (использует переключение задач 386 и т. д.) и, вероятно, никогда не будет поддерживать ничего, кроме AT-жестких дисков, поскольку это все, что у меня есть :-(.

17 сентября 1991 года Торвальдс подготовил версию Linux 0.01 и разместил ее на «ftp.funet.fi» — FTP-сервере Финской университетской и исследовательской сети ( FUNET ). Он даже не был исполняемым, поскольку его код все еще нуждался в Minix для компиляции и тестирования.

5 октября 1991 года Торвальдс анонсировал первую «официальную» версию Linux — 0.02.

[Как] я уже говорил месяц назад, я работаю над бесплатной версией Minix-аналога для компьютеров AT-386. Наконец-то он достиг той стадии, когда его можно даже использовать (хотя это может быть и не в зависимости от того, что вы хотите), и я готов выложить исходники для более широкого распространения. Это всего лишь версия 0.02... но я успешно запускал под ней bash, gcc, gnu-make, gnu-sed, compress и т. д.

Linux быстро рос, поскольку MINIX . в проект внесли свой вклад многие разработчики, включая сообщество В то время проект GNU завершил работу над многими компонентами для своей бесплатной замены UNIX, ОС GNU , но его ядро, GNU Hurd , было неполным. В качестве своей ОС проект принял ядро ​​Linux.

Торвальдс присвоил ядру номер основной версии 0, чтобы указать, что оно еще не предназначено для общего использования. Версия 0.11, выпущенная в декабре 1991 года, была первой версией, размещаемой на собственном хостинге ; скомпилирован на компьютере под управлением ядра Linux.

Когда Торвальдс выпустил версию 0.12 в феврале 1992 года, он принял Стандартную общественную лицензию GNU версии 2 (GPLv2) вместо своей предыдущей лицензии, разработанной им самим, которая не допускала коммерческого распространения. В отличие от Unix , все исходные файлы Linux находятся в свободном доступе, включая драйверы устройств .

Первоначальный успех Linux был обусловлен программистами и тестировщиками по всему миру. Благодаря поддержке POSIX API через libC, которая при необходимости действует как точка входа в адресное пространство ядра, Linux может запускать программное обеспечение и приложения, разработанные для Unix.

Ядро Linux поддерживает различные аппаратные архитектуры, обеспечивая общую платформу для программного обеспечения, включая проприетарное программное обеспечение .

19 января 1992 года было отправлено первое сообщение в новую группу новостей alt.os.linux . 31 марта 1992 года группа новостей была переименована в comp.os.linux .

Тот факт, что Linux представляет собой монолитное ядро, а не микроядро, был темой спора между Эндрю С. Таненбаумом , создателем MINIX, и Торвальдсом. Дебаты Таненбаума и Торвальдса начались в 1992 году в Usenet группе comp.os.minix как общее обсуждение архитектуры ядра.

Версия 0.95 была первой версией, поддерживающей X Window System . В марте 1994 года был выпущен Linux 1.0.0 с 176 250 строками кода. Судя по номеру версии, это была первая версия, считавшаяся подходящей для производственной среды . В июне 1996 года, после выпуска 1.3, Торвальдс решил, что Linux достаточно развился, чтобы гарантировать новый основной номер, и поэтому обозначил следующий выпуск как версию 2.0.0. Важные функции версии 2.0 включали симметричную многопроцессорную обработку (SMP), поддержку большего количества типов процессоров и поддержку выбора конкретных аппаратных целей, а также включение функций и оптимизаций, специфичных для архитектуры. Семейство команд make *config команды kbuild включает и настраивает параметры для создания специальных исполняемых файлов ядра ( vmlinux ) и загружаемых модулей.

Версия 2.2, выпущенная 20 января 1999 г., улучшена детализация блокировок и управление SMP, добавлена ​​поддержка m68k , PowerPC , Sparc64 , Alpha и других 64-битных платформ. Кроме того, были добавлены новые файловые системы , включая Microsoft . от NTFS возможность чтения только для чтения В 1999 году IBM опубликовала свои исправления к коду Linux 2.2.13 для поддержки архитектуры S/390 .

Версия 2.4.0, выпущенная 4 января 2001 г., содержала поддержку ISA Plug and Play , USB и PC Cards . В Linux 2.4 добавлена ​​поддержка Pentium 4 и Itanium (последний представил ia64 ISA, который был совместно разработан Intel и Hewlett-Packard для замены старого PA-RISC ), а также нового 64-битного процессора MIPS . Разработка для 2.4. x немного изменился: на протяжении всей серии стало доступно больше функций, включая поддержку Bluetooth , диспетчера логических томов (LVM) версии 1, RAID поддержку InterMezzo и ext3 , файловых систем .

Версия 2.6.0 была выпущена 17 декабря 2003 г. Разработка для 2.6. x были внесены дальнейшие изменения в сторону включения новых функций во всю серию. Среди изменений, внесенных в серию 2.6, можно отметить: интеграцию μClinux в основные исходные коды ядра, поддержку PAE , поддержку нескольких новых линеек процессоров , интеграцию Advanced Linux Sound Architecture (ALSA) в основные исходные коды ядра, поддержку до 2 ³² пользователи (вместо 2 ¹⁶ ), поддержка до 2 ²⁹ идентификаторы процессов (только 64-битные, 32-битные архитектуры по-прежнему ограничены двумя ¹⁵ ), существенно увеличено количество типов устройств и количество устройств каждого типа, улучшена поддержка 64-бит , поддержка файловых систем , поддерживающих размеры файлов до 16 терабайт внутри ядра , вытеснение , поддержка Native POSIX Thread Library (NPTL) ), интеграция Linux в пользовательском режиме с основными исходными кодами ядра, интеграция SELinux с основными исходными кодами ядра, поддержка InfiniBand и многое другое.

Начиная с выпусков 2.6.x ядро ​​поддерживало большое количество файловых систем; некоторые предназначены для Linux, например ext3 , ext4 , FUSE , Btrfs , и другие, встроенные в другие операционные системы, такие как JFS , XFS , Minix, Xenix , Irix , Solaris , System V , Windows и MS-DOS .

при разработке не использовалась система контроля версий Хотя до сих пор , в 2002 году разработчики Linux приняли BitKeeper , который стал для них бесплатным, хотя и не был свободным программным обеспечением . В 2005 году из-за попыток реконструировать его компания, владевшая этим программным обеспечением, прекратила поддержку сообщества Linux. В ответ Торвальдс и другие написали Git . Новая система была написана за несколько недель, а через два месяца было выпущено первое официальное ядро, созданное с ее использованием.

В 2005 году команда стабильных разработчиков была сформирована в ответ на отсутствие дерева ядра, где люди могли бы работать над исправлением ошибок , и она продолжала обновлять стабильные версии. В феврале 2008 года было создано дерево linux-next , которое служило местом сбора патчей, предназначенных для объединения во время следующего цикла разработки. Некоторые сопровождающие подсистем также использовали суффикс -next для деревьев, содержащих код, который они собираются отправить для включения в следующий цикл выпуска. По состоянию на январь 2014 г. , версия Linux, находящаяся в разработке, хранится в нестабильной ветке с именем linux-next .

20-летие Linux Торвальдс отметил в июле 2011 года выпуском версии 3.0.0. Поскольку номер версии 2.6 был номером версии в течение 8 лет, в ядро ​​пришлось добавить новую личность uname26 , которая сообщает 3.x как 2.6.40+x, чтобы старые программы работали.

Версия 3.0 была выпущена 22 июля 2011 года. 30 мая 2011 года Торвальдс объявил, что большим изменением является «НИЧЕГО. Абсолютно ничего». и спросил: «...давайте убедимся, что мы действительно сделаем следующий выпуск не просто новым блестящим номером, но и хорошим ядром». После ожидаемых 6–7 недель процесса разработки он будет выпущен к 20-летию Linux.

11 декабря 2012 года Торвальдс решил снизить сложность ядра, удалив поддержку процессоров i386 , в частности, отказавшись от эмуляции. атомарная представленная инструкция CMPXCHG, в i486 для обеспечения надежных мьютексов , делает серию ядер 3.7 последней, все еще поддерживающей исходный процессор. В этой же серии унифицирована поддержка процессора ARM .

Изменение нумерации с 2.6.39 на 3.0 и с 3.19 на 4.0 не повлекло за собой значимой технической дифференциации; основной номер версии был увеличен просто для того, чтобы избежать больших второстепенных номеров. Стабильные ядра 3.xy были выпущены до версии 3.19 в феврале 2015 года. Версия 3.11, выпущенная 2 сентября 2013 года, добавлено много новых функций, таких как новые Флаг O_TMPFILE для open(2) для уменьшения временных уязвимостей файлов, экспериментальное динамическое управление питанием AMD Radeon , опрос сети с малой задержкой и zswap (сжатый кэш подкачки).

В апреле 2015 года Торвальдс выпустил версию ядра 4.0. К февралю 2015 года Linux получил вклад почти от 12 000 программистов из более чем 1200 компаний, включая некоторых крупнейших мировых поставщиков программного и аппаратного обеспечения. Версия Linux 4.1, выпущенная в июне 2015 года, содержит более 19,5 миллионов строк кода, написанного почти 14 000 программистами.

В общей сложности 1991 разработчик, из которых 334 работали впервые, добавили более 553 000 строк кода в версию 5.8, побив рекорд, ранее установленный версией 4.9.

Популярность

Основная статья: Доля использования операционных систем

Согласно ежегодному опросу разработчиков Stack Overflow за 2019 год, более 53% всех респондентов разработали программное обеспечение для Linux и около 27% для Android . хотя только около 25% разрабатываются с использованием операционных систем на базе Linux.

Большинство веб-сайтов работают в операционных системах на базе Linux . и все 500 самых мощных суперкомпьютеров в мире используют ту или иную ОС на базе Linux.

Дистрибутивы Linux включают ядро ​​с системным программным обеспечением (например, библиотекой GNU C , systemd и другими Unix утилитами и демонами ) и широким набором прикладного программного обеспечения , но доля их использования на настольных компьютерах невелика по сравнению с другими операционными системами.

Поскольку на Android , то есть Linux, приходится большинство операционных систем мобильных устройств, и из-за растущего использования во встраиваемых устройствах Android в значительной степени ответственен за рост использования Linux в целом.

Ценить

Стоимость доработки ядра Linux

Стоимость переразработки версии 2.6.0 ядра Linux в рамках традиционной проприетарной разработки оценивается в 612 миллионов долларов США (467 миллионов евро, 394 миллиона фунтов стерлингов) в ценах 2004 года с использованием модели оценки человеко-месяца COCOMO . В 2006 году исследование, профинансированное Европейским Союзом, показало, что стоимость доработки ядра версии 2.6.8 выше и составила 882 миллиона евро (1,14 миллиарда долларов, 744 миллиона фунтов стерлингов).

К этой теме вновь обратились в октябре 2008 года Аманда Макферсон, Брайан Проффитт и Рон Хейл-Эванс. Используя методологию Дэвида А. Уиллера, они подсчитали, что переработка ядра 2.6.25 теперь стоит 1,3 миллиарда долларов (часть от общей суммы в 10,8 миллиарда долларов, потраченной на переработку Fedora 9). Опять же, Гарсия-Гарсия и Алонсо де Магдалено из Университета Овьедо (Испания) подсчитали, что стоимость, ежегодно добавляемая к ядру, составляла около 100 миллионов евро в период с 2005 по 2007 год и 225 миллионов евро в 2008 году, это также будет стоить более 1 миллиарда евро (около 1,4 миллиарда долларов). по состоянию на февраль 2010 г.) для разработки в Европейском Союзе.

По состоянию на 7 марта 2011 г. , using then-current LOC (lines of code) of a 2.6.x Linux kernel and wage numbers with David A. Wheeler's calculations it would cost approximately $3bn (about €2.2bn) to redevelop the Linux kernel as it keeps getting bigger. An updated calculation as of 26 September 2018, используя текущие на тот момент 20 088 609 LOC (строк кода) для ядра Linux 4.14.14 и текущую среднюю зарплату программиста в США в 75 506 долларов США, показывают, что переписать существующий код будет стоить примерно 14 725 449 000 долларов США (11 191 341 000 фунтов стерлингов).

Распределение

Большинство тех, кто использует Linux, делают это через дистрибутив Linux . Некоторые дистрибутивы поставляются с ванильным или стабильным ядром. Однако некоторые поставщики (например, Red Hat и Debian ) поддерживают собственное дерево исходного кода. Они обычно обновляются медленнее, чем ванильная ветка, и обычно включают все исправления из соответствующей стабильной ветки, но в то же время они также могут добавлять поддержку драйверов или функций, которые не были выпущены в ванильной версии дистрибутива. Вендор начал основывать свой филиал с.

Разработчики

Сообщество

Интел

Никто

Красная шляпа

Линаро

Неизвестный

ИБМ

Консультанты

Samsung

СУЗЕ

Google

почти 500 других
компании

Корпоративная принадлежность вкладов в ядро ​​Linux, 4.8–4.13

Сообщество разработчиков ядра Linux насчитывает около 5000–6000 участников. Согласно исследованию Linux Foundation «Состояние разработки ядра Linux в 2017 году», охватывающему коммиты для выпусков с 4.8 по 4.13, в среднем около 1500 разработчиков внесли свой вклад из примерно 200–250 компаний. Топ-30 разработчиков внесли чуть более 16% кода. Среди компаний наибольший вклад вносят Intel (13,1%) и Red Hat (7,2%), Linaro (5,6%), IBM (4,1%), второе и пятое места занимают «нет» (8,2%) и «нет». неизвестные» (4,1%) категории.

Вместо дорожной карты — технические рекомендации. Вместо централизованного распределения ресурсов существуют люди и компании, которые заинтересованы в дальнейшем развитии ядра Linux совершенно независимо друг от друга:Такие люди, как Линус Торвальдс и я, не планируют эволюцию ядра. Мы не сидим и не продумываем план действий на следующие два года, а затем распределяем ресурсы на различные новые функции. Это потому, что у нас нет ресурсов. Все ресурсы принадлежат различным корпорациям, которые используют и вносят свой вклад в Linux, а также различным независимым участникам. Решают те люди, которые владеют ресурсами...

— Эндрю Мортон , 2005 г.

Конфликт

Известные конфликты среди разработчиков ядра Linux:

• В июле 2007 года Кон Коливас объявил, что прекращает разработку ядра Linux.
• В июле 2009 года Алан Кокс оставил свою должность сопровождающего TTY после разногласий с Торвальдсом.
• В декабре 2010 года между сопровождающим Linux SCSI Джеймсом Боттомли и сопровождающим SCST Владиславом Болховитиным состоялась дискуссия о том, какой целевой стек SCSI следует включить в ядро ​​Linux. Это расстроило некоторых пользователей Linux.
• В июне 2012 года Торвальдс ясно дал понять, что он не согласен с тем, чтобы NVIDIA выпускала свои драйверы как закрытые.
• В апреле 2014 года Торвальдс запретил Кею Сиверсу отправлять исправления для ядра Linux за неспособность устранить ошибки , из-за которых systemd отрицательно взаимодействовал с ядром.
• В октябре 2014 года Леннарт Пёттеринг обвинил Торвальдса в том, что он терпит грубый стиль обсуждения в списках рассылки, связанных с ядром Linux, и в том, что он является плохим образцом для подражания.
• В марте 2015 года Кристоф Хеллвиг подал иск против VMware за нарушение авторских прав на ядро ​​Linux. Линус Торвальдс дал понять, что не согласен с этой и подобными инициативами, назвав адвокатов гноящейся болезнью.
• В апреле 2021 года было обнаружено, что команда из Университета Миннесоты в рамках своего исследования отправляла «недобросовестные» исправления для ядра. Это привело к немедленному отмене всех патчей, когда-либо отправленных сотрудниками университета. Кроме того, старший специалист по сопровождению предупредил, что любой будущий патч от университета будет отклонен сразу же.

Выдающиеся разработчики ядра Linux осознавали важность предотвращения конфликтов между разработчиками. Из-за противодействия Торвальдса долгое время не существовало кодекса поведения для разработчиков ядра. Однако Кодекс конфликтов ядра Linux. 8 марта 2015 года был представлен 16 сентября 2018 года он был заменен новым Кодексом поведения, основанным на Соглашении с вкладчиками . Это совпало с публичными извинениями Торвальдса и кратким перерывом в разработке ядра. 30 ноября 2018 года, в соответствии с Кодексом поведения , Яркко Саккинен из Intel разослал патчи, заменяющие слова «ебать», встречающиеся в комментариях к исходному коду, подходящими версиями, сосредоточенными на слове «обнимать».

Разработчики, которые считают, что с ними обошлись несправедливо, могут сообщить об этом в Технический консультативный совет Linux Foundation . В июле 2013 года разработчик драйвера USB 3.0 Сейдж Шарп попросил Торвальдса устранить оскорбительные комментарии в сообществе разработчиков ядра. В 2014 году Шарп отказался от разработки ядра Linux, заявив, что «ориентация на техническое совершенство в сочетании с перегруженностью специалистов по сопровождению и людьми с разными культурными и социальными нормами означает, что специалисты по сопровождению ядра Linux часто бывают резкими, грубыми или жестокими, чтобы получить их работа выполнена». На конференции linux.conf.au (LCA) в 2018 году разработчики выразили мнение, что за последние несколько лет культура сообщества стала намного лучше. Дэниел Веттер, сопровождающий драйвера графического ядра Intel drm/i915, отметил, что «довольно жестокие выражения и дискуссии» в сообществе ядра уменьшились или исчезли.

Лоран Пиншар попросил разработчиков поделиться своим опытом взаимодействия с сообществом ядра на Европейской конференции по встроенному Linux 2017 года. Поднятые вопросы были обсуждены несколько дней спустя на Саммите сопровождающих. Обеспокоенность по поводу отсутствия последовательности в том, как сопровождающие реагировали на исправления, представленные разработчиками, была поддержана Шуа Ханом , сопровождающим среды самотестирования ядра. Торвальдс утверждал, что никогда не будет единообразия в обработке исправлений, поскольку разные подсистемы ядра с течением времени применяли разные процессы разработки. Поэтому было решено, что каждый сопровождающий подсистемы ядра будет документировать правила принятия исправлений.

Разработка

Linux — это эволюция, а не разумный замысел !

— Линус Торвальдс, 2005 г.

Кодовая база

Исходный код ядра, также известный как дерево исходного кода, управляется в Git системе контроля версий , также созданной Торвальдсом.

По состоянию на 2021 год Версия ядра Linux 5.11 содержала около 30,34 миллиона строк кода. Примерно 14% кода является частью «ядра» (каталоги Arch, Kernel и mm), а 60% — это драйверы.

Взносы

Вклады отправляются в виде исправлений в виде текстовых сообщений в список рассылки ядра Linux (LKML) (а часто также в другие списки рассылки, посвященные конкретным подсистемам). Патчи должны соответствовать набору правил и формальному языку, который, среди прочего, описывает, какие строки кода следует удалить, а какие еще следует добавить в указанные файлы. Эти исправления могут автоматически обрабатываться, чтобы системные администраторы могли применять их для внесения лишь некоторых изменений в код или для постепенного обновления до следующей версии. Linux также распространяется в форматах GNU zip (gzip) и bzip2 .

Разработчик, желающий изменить ядро ​​Linux, пишет и тестирует изменение кода. В зависимости от того, насколько значительным является изменение и сколько подсистем оно модифицирует, изменение будет представлено либо в виде одного исправления, либо в виде нескольких исправлений исходного кода . В случае, если одна подсистема обслуживается одним сопровождающим, эти исправления отправляются по электронной почте сопровождающему подсистемы с соответствующим списком рассылки в поле Cc. Сопровождающий и читатели списка рассылки будут просматривать исправления и оставлять отзывы. После завершения процесса проверки специалист по сопровождению подсистемы принимает исправления в соответствующем дереве ядра Git . Если изменения в ядре Linux представляют собой исправления ошибок, которые считаются достаточно важными, запрос на получение исправлений будет отправлен Торвальдсу в течение нескольких дней. В противном случае запрос на включение будет отправлен Торвальдсу во время следующего окна слияния. Окно слияния обычно длится две недели и начинается сразу после выпуска предыдущей версии ядра. В дереве исходного кода ядра Git имена всех разработчиков, внесших вклад в ядро ​​Linux, указаны в каталоге «Credits» , а все сопровождающие подсистемы перечислены в разделе «Maintainers» .

Как и во многих крупных проектах программного обеспечения с открытым исходным кодом, разработчики обязаны соблюдать Соглашение участников , — кодекс поведения предназначенный для борьбы с преследованием участников меньшинства. использование инклюзивной терминологии в исходном коде. Кроме того, во избежание нарушений обязательно

Язык программирования

См. также: Rust для Linux.

Linux написан на специальном языке программирования C, поддерживаемом GCC , компилятором, который расширяет стандарт C во многих отношениях, например, с использованием встроенных разделов кода, написанных на языке ассемблера (в синтаксисе GCC «AT&T-style») целевой архитектуры. .

В сентябре 2021 года требования к версии GCC для компиляции и сборки ядра Linux были увеличены с GCC 4.9 до 5.1, что позволяет перейти от использования кода C на основе стандарта C89 к использованию кода, написанного с использованием стандарта C11 . при этом переход на стандарт состоится в марте 2022 года с выпуском Linux 5.18.

Первоначальная поддержка языка программирования Rust была добавлена ​​в Linux 6.1. который был выпущен в декабре 2022 года, с более поздними версиями ядра, такими как Linux 6.2 и Linux 6.3, что еще больше улучшает поддержку.

Стиль кодирования

С 2002 года код должен соответствовать 21 правилу, составляющему стиль кодирования ядра Linux.

Управление версиями

Что касается большинства программ, версия ядра обозначается серией чисел, разделенных точками.

В ранних версиях версия состояла из трех или четырех чисел, разделенных точками, называемых основным выпуском , второстепенным выпуском и версией. В то время второстепенные выпуски с нечетными номерами предназначались для разработки и тестирования, а второстепенные выпуски с четными номерами - для производства. Необязательная четвертая цифра указывает уровень исправления. Версии разработки обозначались суффиксом-кандидатом на выпуск ( -rc ).

Текущие соглашения о версиях другие. Нечетное/четное число, подразумевающее dev/prod, было опущено, а основная версия обозначается первыми двумя цифрами вместе. Хотя временные рамки для разработки следующей основной версии открыты, суффикс -rcN используется для обозначения n-го кандидата на выпуск следующей версии. Например, выпуску версии 4.16 предшествовало семь 4.16-rcN (от -rc1 до -rc7). После выпуска стабильной версии ее обслуживание передается команде разработчиков стабильной версии . Обновления стабильной версии обозначаются трехзначной схемой (например, 4.16.1, 4.16.2, ...).

Инструментальная цепочка

Ядро обычно собирается с помощью инструментария GNU . Компилятор GNU C, GNU cc, входящий в коллекцию компиляторов GNU (GCC), является компилятором по умолчанию для основной версии Linux. Секвенированием занимается GNU make . Ассемблер GNU (часто называемый GAS или GNU as) выводит объектные файлы кода , сгенерированного GCC из ассемблерного . Наконец, компоновщик GNU (GNU ld) создает статически связанный исполняемый файл ядра, называемый vmlinux . Оба как и ld являются частью двоичных утилит GNU (binutils).

GNU cc долгое время был единственным компилятором, способным правильно собирать Linux. В 2004 году Intel заявила, что модифицировала ядро ​​так, чтобы его компилятор C также мог его компилировать. Еще один подобный успех был зарегистрирован в 2009 году с модифицированной версией 2.6.22. Поддержка компилятора Intel прекращена в 2023 году.

С 2010 года предпринимаются усилия по созданию Linux с Clang , альтернативным компилятором для языка C; по состоянию на 12 апреля 2014 г. официальное ядро ​​почти можно было скомпилировать с помощью Clang. Проект, посвященный этим усилиям, называется LLVMLinux в честь инфраструктуры компилятора LLVM , на которой построен Clang. LLVMLinux не преследует цель создать форк Linux или LLVM, поэтому это метапроект, состоящий из патчей, которые в конечном итоге передаются вышестоящим проектам. Включив компиляцию Linux с помощью Clang, разработчики могут получить выгоду от сокращения времени компиляции.

В 2017 году разработчики завершили выпуск исправлений для поддержки сборки ядра Linux с помощью Clang в выпуске 4.15, перенеся поддержку X86-64 и AArch64 в ветки стабильного дерева ядра 4.4, 4.9 и 4.14. Google Pixel 2 поставляется с первым Clang . , построенным на Linux ядром хотя патчи для Pixel (1-го поколения) существовали. В 2018 году ChromeOS перешла на сборку ядер с использованием Clang по умолчанию. в то время как Android (операционная система) создала Clang и LLVM компоновщик LLD требуется для сборок ядра в 2019 году. В 2020 году Google перевела свое рабочее ядро, используемое в своих центрах обработки данных, на сборку с помощью Clang . Сегодня группа ClangBuiltLinux координирует исправления как для Linux, так и для LLVM , чтобы обеспечить совместимость, обе группы состоят из членов LLVMLinux и имеют исходные исправления от LLVMLinux .

Отладка

Основные статьи: KGDB , Kernel Panic и Linux kernel oops

Вывод паники ядра Linux

Как и в случае с любым другим программным обеспечением, проблемы с ядром Linux бывает сложно устранить . Общие проблемы связаны с доступом к пространству пользователя и пространству ядра, неправильному использованию примитивов синхронизации и неправильному управлению оборудованием.

Упс — это нефатальная ошибка в ядре. После такой ошибки операции продолжаются с подозрительной надежностью.

Паника (созданная паника() ) является фатальной ошибкой. После такой ошибки ядро ​​выводит сообщение и останавливает компьютер.

Ядро обеспечивает отладку путем печати через printk () , который сохраняет сообщения в кольцевом буфере (перезаписывая старые записи новыми). Системный вызов syslog(2) обеспечивает чтение и очистку буфера сообщений, а также установку максимального уровня журнала сообщений, отправляемых на консоль. Сообщения ядра также экспортируются в пользовательскую среду через интерфейс /dev/kmsg .

Механизм ftrace позволяет выполнять отладку путем трассировки. Он используется для мониторинга и отладки Linux во время выполнения и может анализировать задержки в пользовательском пространстве из-за неправильного поведения ядра. Более того, ftrace позволяет пользователям отслеживать Linux во время загрузки.

kprobes и kretprobes могут прерывать выполнение ядра (как отладчики в пользовательском пространстве) и собирать информацию без прерывания работы. kprobes можно вставлять в код (почти) по любому адресу, а kretprobes работают при возврате функции. У зондов схожие цели, но они также имеют некоторые различия в использовании и реализации.

С помощью KGDB Linux можно отлаживать почти так же, как и программы пользовательского пространства. Для KGDB требуется дополнительная машина, на которой работает GDB и которая подключена к цели для отладки с помощью последовательного кабеля или Ethernet .

Процесс изменения

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

За каждой подсистемой ядра закреплен специалист по сопровождению, который отвечает за проверку исправлений на соответствие стандартам кода ядра и поддерживает очередь исправлений, которые могут быть отправлены Торвальдсу в течение окна слияния, которое обычно длится несколько недель.

Патчи объединяются Торвальдсом с исходным кодом предыдущей стабильной версии ядра Linux, создавая кандидата на выпуск (-rc) для следующей стабильной версии. После закрытия окна слияния принимаются только исправления нового кода в разрабатываемой версии. Разрабатываемая версия ядра -rc проходит регрессионное тестирование , и как только Торвальдс и сопровождающие подсистемы считают ее стабильной, выпускается новая версия, и процесс разработки начинается заново.

Основной Linux

Дерево Git, содержащее исходный код ядра Linux, называется основной веткой Linux . Каждый стабильный выпуск ядра происходит из основного дерева. и часто публикуется на kernel.org . Mainline Linux имеет надежную поддержку лишь для небольшого подмножества многих устройств, работающих под управлением Linux. Неосновная поддержка обеспечивается независимыми проектами, такими как Yocto или Linaro , но во многих случаях необходимо ядро ​​от поставщика устройства. Для использования ядра поставщика, вероятно, потребуется пакет поддержки платы .

Поддержка дерева ядра за пределами основной версии Linux оказалась сложной задачей.

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

Linux-подобное ядро

Сопровождающий стабильной ветки Грег Кроа-Хартман применил термин «Linux-подобный» к последующим вилкам ядра от поставщиков, которые добавляют миллионы строк кода в основное ядро. В 2019 году Google заявила, что хочет использовать основное ядро ​​Linux в Android, чтобы сократить количество вилок ядра. Термин «подобный Linux» также применяется к подмножеству встраиваемого ядра Linux , которое включает не полное основное ядро ​​Linux, а небольшое модифицированное подмножество кода.

Развилки Linux

iPod ​ загружает iPodLinux

Существуют определенные сообщества, которые разрабатывают ядра на основе официального Linux. Некоторые интересные фрагменты кода из этих ответвлений , в том числе Linux-libre , Compute Node Linux , INK , L4Linux , RTLinux и User-Mode Linux (UML), были объединены в основную ветку. Некоторые операционные системы, разработанные для мобильных телефонов, изначально использовали сильно модифицированные версии Linux, включая Google Android , Firefox OS , HP webOS , Nokia Maemo и Jolla Sailfish OS . В 2010 году сообщество Linux раскритиковало Google за эффективное создание собственного дерева ядра:

Это означает, что любые драйверы, написанные для аппаратных платформ Android, не могут быть объединены с основным деревом ядра, поскольку они зависят от кода, который находится только в дереве ядра Google, что приводит к невозможности его сборки в дереве kernel.org. Из-за этого Google теперь предотвратил слияние большого количества аппаратных драйверов и кода платформы с основным деревом ядра. Эффективное создание ветки ядра, на которую сейчас полагаются несколько различных поставщиков.

— Грег Кроа-Хартман , 2010 г.

Сегодня Android использует настроенный Linux где основные изменения реализованы в драйверах устройств, но требуются некоторые изменения в основном коде ядра. Разработчики Android также отправляют исправления для официального Linux, которые, наконец, могут загружать операционную систему Android. Например, Nexus 7 может загружать и запускать основной Linux.

На презентации 2001 года в Музее компьютерной истории Торвальдс сказал следующее в ответ на вопрос о том, используют ли дистрибутивы Linux точно такие же исходные коды ядра или нет:

Они не... ну, они есть, и это не так. Единого ядра нет. В каждом дистрибутиве есть свои изменения. Это продолжается практически с первого дня. Я не знаю, помните ли вы, что Yggdrasil был известен своими весьма радикальными изменениями в ядре, и даже сегодня у всех основных поставщиков есть свои собственные настройки, потому что у них есть определенная часть рынка, которая им интересна, и, откровенно говоря, именно так так и должно быть. Потому что, если все ожидают, что один человек, я, сможет отслеживать все, это не является целью GPL. Суть открытой системы не в этом. Так что на самом деле тот факт, что дистрибутив решает, что что-то настолько важно для них, что они будут добавлять патчи, даже если этого нет в стандартном ядре, это действительно хороший знак для меня. Вот, например, как было добавлено что-то вроде ReiserFS. И причина, по которой ReiserFS стала первой журналируемой файловой системой, интегрированной в стандартное ядро, заключалась не в том, что я люблю Ханса Райзера. Это произошло потому, что SUSE фактически начала поставлять ReiserFS в качестве стандартного ядра, и это сказало мне «хорошо». Это фактически используется в производстве. Нормальные люди так делают. Они, должно быть, знают что-то, чего я не знаю. Таким образом, в самом прямом смысле то, что делают многие дистрибьюторские дома, они являются частью этого подхода «давайте создадим наш собственный филиал» и «давайте внесем в него свои изменения». А благодаря лицензии GPL я могу забрать лучшие из них.

— Линус Торвальдс , 2001 г.

Долгосрочная поддержка

Загрузочные сообщения ядра Linux 2.6.25.17

Последняя и более ранние версии поддерживаются отдельно. Большинство последних выпусков ядра курировались Торвальдсом.

Сообщество разработчиков ядра Linux поддерживает стабильное ядро, применяя исправления программных ошибок , обнаруженных во время разработки последующего стабильного ядра. Поэтому на сайте www.kernel.org всегда указаны два стабильных ядра. Следующее стабильное ядро ​​Linux будет выпущено примерно через 8–12 недель.

Некоторые выпуски предназначены для долгосрочной поддержки как долгосрочные с выпусками с исправлениями ошибок в течение двух или более лет.

Архитектура и особенности

См. также: vmlinux

Карта ядра Linux

Диаграмма Санки строк исходного кода ядра Linux

Несмотря на кажущуюся противоречивость, ядро ​​Linux одновременно монолитно и модульно. Ядро классифицируется как монолитное по архитектуре, поскольку вся ОС работает в пространстве ядра. Конструкция является модульной, поскольку ее можно собрать из модулей , которые в некоторых случаях загружаются и выгружаются во время выполнения. Он поддерживает функции, которые когда-то были доступны только в ядрах с закрытым исходным кодом несвободных операционных систем.

В оставшейся части статьи используются соглашения UNIX и Unix-подобных операционных систем, описанные в руководствах . Число, которое следует за именем команды, интерфейса или другой функции, указывает раздел (т. е. тип компонента или функции ОС), к которому она принадлежит. Например execve(2) относится к системному вызову, а exec(3) относится к оболочке библиотеки пользовательского пространства.

Ниже приводится обзор архитектурного дизайна и примечательных особенностей.

• Параллельные вычисления и (при наличии достаточного количества ядер ЦП для готовых к выполнению задач) даже настоящее параллельное выполнение множества процессов одновременно (каждый из которых имеет один или несколько потоков выполнения ) на SMP и NUMA . архитектурах
• Выбор и настройка сотен функций ядра и драйверов (с использованием одного из make *config перед сборкой), семейство команд модификация параметров ядра перед загрузкой (обычно путем вставки инструкций в строки меню GRUB2 ) и точная настройка поведения ядра во время выполнения (с использованием команды sysctl(8) интерфейс для /proc/sys/ ).
• Конфигурация (снова используя команды make *config ) и изменения политик во время выполнения. (с помощью приятно(2) , setpriority(2) и семейство sched_*(2) системные вызовы) планировщиков задач , которые обеспечивают вытесняющую многозадачность (как в пользовательском режиме , так и, начиная с серии 2.6, в режиме ядра) . ); самый ранний подходящий планировщик виртуального крайнего срока первого планирования (EEVDF), является планировщиком по умолчанию в Linux с 2023 года и использует красно-черное дерево , которое может искать, вставлять и удалять информацию о процессе ( структуру задачи ) с O(log n) временной сложностью , где n — количество выполняемых задач.
• Расширенное управление памятью с помощью выгружаемой виртуальной памяти .
• Межпроцессные коммуникации и механизм синхронизации .
• Виртуальная файловая система поверх нескольких конкретных файловых систем ( ext4 , Btrfs , XFS , JFS , FAT32 и многих других).
• Настраиваемые планировщики ввода-вывода, ioctl(2) системный вызов, который манипулирует параметрами базового устройства специальных файлов (это нестандартный системный вызов, поскольку аргументы, возвраты и семантика зависят от рассматриваемого драйвера устройства), поддержка асинхронного ввода-вывода POSIX (однако, поскольку они плохо масштабируются с многопоточными приложениями, семейство системных вызовов ввода-вывода, специфичных для Linux ( это_*(2) ) необходимо было создать для управления контекстами асинхронного ввода-вывода, подходящими для параллельной обработки).
• Виртуализация на уровне ОС (с помощью Linux-VServer ), паравиртуализация и аппаратная виртуализация (с помощью KVM или Xen и использование QEMU для эмуляции оборудования); Xen В гипервизоре ядро ​​Linux обеспечивает поддержку сборки дистрибутивов Linux (таких как openSUSE Leap и многих других), которые работают как Dom0 , которые представляют собой хост-серверы виртуальных машин, обеспечивающие среду управления виртуальными машинами пользователя ( DomU ).
• Виртуализация ввода-вывода с помощью VFIO и SR-IOV . Виртуальный функциональный ввод-вывод (VFIO) предоставляет прямой доступ устройства к пользовательскому пространству в защищенной среде безопасной памяти (IOMMU). С помощью VFIO гость виртуальной машины может напрямую обращаться к аппаратным устройствам на хост-сервере виртуальной машины. Этот метод повышает производительность по сравнению с полной виртуализацией и паравиртуализацией. Однако с помощью VFIO устройства не могут совместно использоваться несколькими гостевыми виртуальными машинами. Виртуализация ввода-вывода с единым корнем (SR-IOV) сочетает в себе повышение производительности VFIO и возможность совместного использования устройства с несколькими гостями виртуальной машины (но для этого требуется специальное оборудование, которое должно быть способно отображаться двум или более гостям виртуальной машины как разные устройства). .
• Механизмы безопасности для дискреционного и обязательного контроля доступа (SELinux, AppArmor, POSIX ACL и другие).
• Несколько типов многоуровневых протоколов связи (включая набор протоколов Интернета ).
• Асимметричная многопроцессорная обработка через подсистему RPMsg .

Большинство драйверов устройств и расширений ядра работают в пространстве ядра ( кольцо 0 во многих ЦП архитектурах ) с полным доступом к оборудованию. Некоторые исключения выполняются в пространстве пользователя ; Яркими примерами являются файловые системы, основанные на FUSE /CUSE и части UIO. Более того, X Window System и Wayland , оконная система и протоколы серверов отображения, которые большинство людей используют в Linux, не работают в ядре. Иными словами, фактическое взаимодействие с процессорами видеокарт графическими представляет собой внутриядерную подсистему, называемую Direct Rendering Manager (DRM).

В отличие от стандартных монолитных ядер, драйверы устройств легко настраиваются как модули и загружаются или выгружаются во время работы системы, а также могут быть вытеснены при определенных условиях, чтобы правильно обрабатывать аппаратные прерывания и лучше поддерживать симметричную многопроцессорность . По выбору Linux не имеет стабильного двоичного интерфейса приложения драйвера устройства .

Linux обычно использует защиту памяти и виртуальную память , а также может обрабатывать неравномерный доступ к памяти . однако проект вобрал в себя μClinux , который также позволяет запускать Linux на микроконтроллерах без виртуальной памяти.

Аппаратное обеспечение представлено в файловой иерархии. Пользовательские приложения взаимодействуют с драйверами устройств через записи в /dev или /sys каталоги. Информация о процессе отображается в /прок каталог.

Различные уровни в Linux, также показывающие разделение между пользовательской областью и пространством ядра.

Пользовательский режим	Пользовательские приложения	bash , LibreOffice , GIMP , Blender , 0 AD , Mozilla Firefox , ...
	Компоненты системы	демон инициализации : OpenRC , runit , systemd ...	Системные демоны : polkitd , smbd , sshd , udevd ...	Оконный менеджер : X11 , Wayland , SurfaceFlinger (Android)	Графика : Меса , катализатор AMD , ...	Другие библиотеки: GTK , Qt , EFL , SDL , SFML , FLTK , GNUstep , ...
	Стандартная библиотека C	fopen, execv, malloc, memcpy, localtime, pthread_create... (до 2000 подпрограмм ) glibc стремится быть быстрым, musl стремится быть легким, uClibc нацелен на встраиваемые системы, bionic написан для Android и т. д. Все стремятся быть POSIX / SUS -совместимыми.
Режим ядра	Ядро Linux	stat, splice, dup, read, open, ioctl, write, mmap, close, exitи т. д. (около 380 системных вызовов) ядра Linux Интерфейс системных вызовов (SCI) должен быть POSIX / SUS -совместимым.
		планирования процессов Подсистема	IPC Подсистема	управления памятью Подсистема	виртуальных файлов Подсистема	Сетевая подсистема
		Другие компоненты: ALSA , DRI , evdev , klibc , LVM , устройство отображения устройств , сетевой планировщик Linux , Netfilter. Модули безопасности Linux : SELinux , TOMOYO , AppArmor , Smack
Аппаратное обеспечение ( ЦП , основная память , устройства хранения данных и т. д.)

Интерфейсы

Основные страницы: Интерфейсы ядра Linux и Интерфейсы ядра Linux (Категория)

См. также: Системный вызов , POSIX и единая спецификация UNIX.

Выделяются четыре интерфейса: два внутренних по отношению к ядру и два между ядром и пользовательским пространством.

Linux начинался как клон UNIX и нацелен на соответствие POSIX и единой спецификации UNIX . Ядро предоставляет системные вызовы и другие интерфейсы, специфичные для Linux. Чтобы быть включенным в официальное ядро, код должен соответствовать набору правил лицензирования.

Linux Бинарный интерфейс приложений (ABI) между ядром и пользовательским пространством имеет четыре степени стабильности (стабильный, тестируемый, устаревший, удаленный); Ожидается, что системные вызовы никогда не изменятся, чтобы сохранить совместимость с программами пользовательского пространства , которые на них полагаются.

Загружаемые модули ядра (LKM) по своей конструкции не могут полагаться на стабильный ABI. Поэтому их необходимо перекомпилировать каждый раз, когда в системе устанавливается новый исполняемый файл ядра, иначе они не будут загружены. Драйверы в дереве, которые настроены стать неотъемлемой частью исполняемого файла ядра ( vmlinux ), статически связываются в процессе сборки.

Нет никакой гарантии стабильности API внутри ядра на уровне исходного кода. и поэтому код драйвера устройства , а также код любой другой подсистемы ядра должен постоянно обновляться по мере развития ядра. Любой разработчик, вносящий изменения в API, обязан исправить любой код, который выходит из строя в результате их изменения.

API ядра-пользователя

Набор API ядра Linux , который касается интерфейсов, предоставляемых пользовательским приложениям, в основном состоит из системных вызовов UNIX и Linux . Системный вызов — это точка входа в ядро ​​Linux. Например, среди Linux-специфичных есть семейство clone(2) . Системные вызовы Большинство расширений необходимо включить, определив _GNU_SOURCE макрос в заголовочном файле или при компиляции пользовательского кода.

Системные вызовы могут быть вызваны только с помощью инструкций ассемблера, которые позволяют перейти из непривилегированного пользовательского пространства в привилегированное пространство ядра в кольце 0 . По этой причине стандартная библиотека C (libC) действует как оболочка для большинства системных вызовов Linux, предоставляя функции C, которые при необходимости прозрачно войти в ядро, которое будет выполняться от имени вызывающего процесса. Для системных вызовов, не предоставляемых libC, таких как быстрый мьютекс пользовательского пространства , библиотека предоставляет функцию под названием syscall(2), который можно использовать для их явного вызова.

Псевдофайловые системы (например, файловые системы sysfs и procfs ) и специальные файлы (например, /dev/random, /dev/sda, /dev/ttyи многие другие) представляют собой еще один уровень интерфейса для структур данных ядра, представляющих аппаратные или логические (программные) устройства.

ABI между ядром и пользовательским пространством

Основная статья: Стандартная база Linux

Из-за различий, существующих между сотнями различных реализаций ОС Linux, исполняемые объекты, даже если они скомпилированы, собраны и скомпонованы для работы на конкретной аппаратной архитектуре (то есть используют ISA целевого оборудования), часто не может работать в разных дистрибутивах Linux. Эта проблема в основном связана с конфигурациями, специфичными для дистрибутива, и набором исправлений, примененных к коду ядра Linux, различиями в системных библиотеках, службах (демонах), иерархиях файловой системы и переменных среды.

The main standard concerning application and binary compatibility of Linux distributions is the Linux Standard Base (LSB). However, the LSB goes beyond what concerns the Linux kernel, because it also defines the desktop specifications, the X libraries and Qt that have little to do with it. The LSB version 5 is built upon several standards and drafts (POSIX, SUS, X/Open, File System Hierarchy (FHS), and others).

The parts of the LSB more relevant to the kernel are the General ABI (gABI), especially the System V ABI and the Executable and Linking Format (ELF), and the Processor Specific ABI (psABI), for example the Core Specification for X86-64.

The standard ABI for how x86_64 user programs invoke system calls is to load the syscall number into the rax register, and the other parameters into rdi, rsi, rdx, r10, r8, and r9, and finally to put the syscall assembly instruction in the code.

In-kernel API

At XDC2014, Alex Deucher from AMD announced the unified kernel-mode driver. The proprietary Linux graphic driver, libGL-fglrx-glx, will share the same DRM infrastructure with Mesa 3D. As there is no stable in-kernel ABI, AMD had to constantly adapt the former binary blob used by Catalyst.

There are several internal kernel APIs between kernel subsystems. Some are available only within the kernel subsystems, while a somewhat limited set of in-kernel symbols (i.e., variables, data structures, and functions) is exposed to dynamically loadable modules (e.g., device drivers loaded on demand) whether they're exported with the EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() macros (the latter reserved to modules released under a GPL-compatible license).

Linux provides in-kernel APIs that manipulate data structures (e.g., linked lists, radix trees, red-black trees, queues) or perform common routines (e.g., copy data from and to user space, allocate memory, print lines to the system log, and so on) that have remained stable at least since Linux version 2.6.

In-kernel APIs include libraries of low-level common services used by device drivers:

• SCSI Interfaces and libATA – respectively, a peer-to-peer packet based communication protocol for storage devices attached to USB, SATA, SAS, Fibre Channel, FireWire, ATAPI device, and an in-kernel library to support [S]ATA host controllers and devices.
• Direct Rendering Manager (DRM) and Kernel Mode Setting (KMS) – for interfacing with GPUs and supporting the needs of modern 3D-accelerated video hardware, and for setting screen resolution, color depth and refresh rate
• DMA buffers (DMA-BUF) – for sharing buffers for hardware direct memory access across multiple device drivers and subsystems
• Video4Linux – for video capture hardware
• Advanced Linux Sound Architecture (ALSA) – for sound cards
• New API – for network interface controllers
• mac80211 and cfg80211 – for wireless network interface controllers

In-kernel ABI

The Linux developers chose not to maintain a stable in-kernel ABI. Modules compiled for a specific version of the kernel cannot be loaded into another version without being recompiled.

Multiprocessing

See also: Process (computing), Thread (computing), and Process management (computing)

Linux creates processes by means of the clone(2) or newer clone3(2) system calls. These syscalls create new entities ranging from new independent processes (each having a special identifier called TGID within the task_struct data structure in kernel space, although that same identifier is called PID in userspace), to new threads within the calling process.

If the executable is dynamically linked to shared libraries, a dynamic linker is used to find and load the needed objects, prepare the program to run and then run it.

The Native POSIX Thread Library (NPTL) provides the POSIX standard thread interface (pthreads) to userspace.

The kernel provides the futex(7) (fast user-space mutex) mechanisms for user-space locking and synchronization. The majority of the operations are performed in userspace but it may be necessary to communicate with the kernel using the futex(2) system call.

As opposed to userspace threads described above, kernel threads run in kernel space.

Scheduling

Main articles: Completely Fair Scheduler and Earliest eligible virtual deadline first scheduling

The Linux process scheduler is modular, in the sense that it enables different scheduling classes and policies. Scheduler classes are plugable scheduler algorithms that can be registered with the base scheduler code. Each class schedules different types of processes. The core code of the scheduler iterates over each class in order of priority and chooses the highest priority scheduler that has a schedulable entity of type struct sched_entity ready to run. Entities may be threads, group of threads, and even all the processes of a specific user.

Linux provides both user preemption as well as full kernel preemption. Preemption reduces latency, increases responsiveness, and makes Linux more suitable for desktop and real-time applications.

For normal tasks, by default, the kernel uses the Completely Fair Scheduler (CFS) class, introduced in version 2.6.23. The scheduler is defined as a macro in a C header as SCHED_NORMAL. In other POSIX kernels, a similar policy known as SCHED_OTHER allocates CPU timeslices (i.e, it assigns absolute slices of the processor time depending on either predetermined or dynamically computed priority of each process). The Linux CFS does away with absolute timeslices and assigns a fair proportion of CPU time, as a function of parameters like the total number of runnable processes and the time they have already run; this function also takes into account a kind of weight that depends on their relative priorities (nice values).

With user preemption, the kernel scheduler can replace the current process with the execution of a context switch to a different one that therefore acquires the computing resources for running (CPU, memory, and more). It makes it according to the CFS algorithm (in particular, it uses a variable called vruntime for sorting entities and then chooses the one that has the smaller vruntime, - i.e., the schedulable entity that has had the least share of CPU time), to the active scheduler policy and to the relative priorities. With kernel preemption, the kernel can preempt itself when an interrupt handler returns, when kernel tasks block, and whenever a subsystem explicitly calls the schedule() function.

The kernel also contains two POSIX-compliant real-time scheduling classes named SCHED_FIFO (realtime first-in-first-out) and SCHED_RR (realtime round-robin), both of which take precedence over the default class. An additional scheduling policy known as SCHED DEADLINE, implementing the earliest deadline first algorithm (EDF), was added in kernel version 3.14, released on 30 March 2014. SCHED_DEADLINE takes precedence over all the other scheduling classes.

Real-time PREEMPT_RT patches, included into the mainline Linux since version 2.6, provide a deterministic scheduler, the removal of preemption and interrupt disabling (where possible), PI Mutexes (i.e., locking primitives that avoid priority inversion), support for High Precision Event Timers (HPET), preemptive read-copy-update (RCU), (forced) IRQ threads, and other minor features.

In 2023, Peter Zijlstra proposed replacing CFS with an earliest eligible virtual deadline first scheduling (EEVDF) scheduler, to prevent the need for CFS "latency nice" patches. The EEVDF scheduler replaced CFS in version 6.6 of the Linux kernel.

Synchronization

The kernel has different causes of concurrency (e.g., interrupts, bottom halves, preemption of kernel and users tasks, symmetrical multiprocessing).

For protecting critical regions (sections of code that must be executed atomically), shared memory locations (like global variables and other data structures with global scope), and regions of memory that are asynchronously modifiable by hardware (e.g., having the C volatile type qualifier), Linux provides a large set of tools. They consist of atomic types (which can only be manipulated by a set of specific operators), spinlocks, semaphores, mutexes, and lockless algorithms (e.g., RCUs). Most lock-less algorithms are built on top of memory barriers for the purpose of enforcing memory ordering and prevent undesired side effects due to compiler optimization.

PREEMPT_RT code included in mainline Linux provide RT-mutexes, a special kind of Mutex which do not disable preemption and have support for priority inheritance. Almost all locks are changed into sleeping locks when using configuration for realtime operation. Priority inheritance avoids priority inversion by granting a low-priority task which holds a contended lock the priority of a higher-priority waiter until that lock is released.

Linux includes a kernel lock validator called Lockdep.

Interrupts

Although the management of interrupts could be seen as a single job, it is divided into two. This split in two is due to the different time constraints and to the synchronization needs of the tasks whose the management is composed of. The first part is made up of an asynchronous interrupt service routine that in Linux is known as the top half, while the second part is carried out by one of three types of the so-called bottom halves (softirq, tasklets, and work queues).

Linux interrupt service routines can be nested. A new IRQ can trap into a high priority ISR that preempts any other lower priority ISR.

Memory

See also: Memory management and Virtual memory

Linux implements virtual memory with 5-level page tables. The kernel is not pageable (meaning it is always resident in physical memory and cannot be swapped to the disk) and there is no memory protection (no SIGSEGV signals, unlike in user space), therefore memory violations lead to instability and system crashes. User memory is pageable by default, although paging for specific memory areas can be disabled with the mlock() system call family.

Page frame information is maintained in apposite data structures (of type struct page) that are populated immediately after boot and kept until shutdown, regardless of whether they are associated with virtual pages. The physical address space is divided into different zones, according to architectural constraints and intended use. NUMA systems with multiple memory banks are also supported.

Small chunks of memory can be dynamically allocated in kernel space via the family of kmalloc() APIs and freed with the appropriate variant of kfree(). vmalloc() and kvfree() are used for large virtually contiguous chunks. alloc_pages() allocates the desired number of entire pages.

The Linux Storage Stack Diagram

The kernel used to include the SLAB, SLUB and SLOB allocators as configurable alternatives. The SLOB allocator was removed in Linux 6.4 and the SLAB allocator was removed in Linux 6.8. The sole remaining allocator is SLUB, which aims for simplicity and efficiency, is PREEMPT_RT compatible and was introduced in Linux 2.6.

Supported architectures

See also: List of Linux-supported computer architectures and Linux-powered device

TiVo DVR, a consumer device running Linux

While not originally designed to be portable, Linux is now one of the most widely ported operating system kernels, running on a diverse range of systems from the ARM architecture to IBM z/Architecture mainframe computers. The first port was performed on the Motorola 68000 platform. The modifications to the kernel were so fundamental that Torvalds viewed the Motorola version as a fork and a "Linux-like operating system". However, that moved Torvalds to lead a major restructure of the code to facilitate porting to more computing architectures. The first Linux that, in a single source tree, had code for more than i386 alone, supported the DEC Alpha AXP 64-bit platform.

Linux runs as the main operating system on IBM's Summit; as of October 2019, all of the world's 500 fastest supercomputers run some operating system based on the Linux kernel, a big change from 1998 when the first Linux supercomputer got added to the list.

Linux has also been ported to various handheld devices such as Apple's iPhone 3G and iPod.

Supported devices

In 2007, the LKDDb project has been started to build a comprehensive database of hardware and protocols known by Linux kernels. The database is built automatically by static analysis of the kernel sources. Later in 2014, the Linux Hardware project was launched to automatically collect a database of all tested hardware configurations with the help of users of various Linux distributions.

Live patching

Rebootless updates can even be applied to the kernel by using live patching technologies such as Ksplice, kpatch and kGraft. Minimalistic foundations for live kernel patching were merged into the Linux kernel mainline in kernel version 4.0, which was released on 12 April 2015. Those foundations, known as livepatch and based primarily on the kernel's ftrace functionality, form a common core capable of supporting hot patching by both kGraft and kpatch, by providing an application programming interface (API) for kernel modules that contain hot patches and an application binary interface (ABI) for the userspace management utilities. However, the common core included into Linux kernel 4.0 supports only the x86 architecture and does not provide any mechanisms for ensuring function-level consistency while the hot patches are applied. As of April 2015, there is ongoing work on porting kpatch and kGraft to the common live patching core provided by the Linux kernel mainline.

Security

Kernel bugs present potential security issues. For example, they may allow for privilege escalation or create denial-of-service attack vectors. Over the years, numerous bugs affecting system security were found and fixed. New features are frequently implemented to improve the kernel's security.

Capabilities(7) have already been introduced in the section about the processes and threads. Android makes use of them and systemd gives administrators detailed control over the capabilities of processes.

Linux offers a wealth of mechanisms to reduce kernel attack surface and improve security which are collectively known as the Linux Security Modules (LSM). They comprise the Security-Enhanced Linux (SELinux) module, whose code has been originally developed and then released to the public by the NSA, and AppArmor among others. SELinux is now actively developed and maintained on GitHub. SELinux and AppArmor provide support to access control security policies, including mandatory access control (MAC), though they profoundly differ in complexity and scope.

Another security feature is the Seccomp BPF (SECure COMPuting with Berkeley Packet Filters) which works by filtering parameters and reducing the set of system calls available to user-land applications.

Critics have accused kernel developers of covering up security flaws, or at least not announcing them; in 2008, Torvalds responded to this with the following:

I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special...one reason I refuse to bother with the whole security circus is that I think it glorifies—and thus encourages—the wrong behavior. It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are way more important, just because there's[sic] a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking.

Linux distributions typically release security updates to fix vulnerabilities in the Linux kernel. Many offer long-term support releases that receive security updates for a certain Linux kernel version for an extended period of time.

Legal

Licensing terms

Initially, Torvalds released Linux under a license which forbade any commercial use. This was changed in version 0.12 by a switch to the GNU General Public License version 2 (GPLv2). This license allows distribution and sale of possibly modified and unmodified versions of Linux but requires that all those copies be released under the same license and be accompanied by - or that, on request, free access is given to - the complete corresponding source code. Torvalds has described licensing Linux under the GPLv2 as the "best thing I ever did".

The Linux kernel is licensed explicitly under GNU General Public License version 2 only (GPL-2.0-only) with an explicit syscall exception (Linux-syscall-note), without offering the licensee the option to choose any later version, which is a common GPL extension. Contributed code must be available under GPL-compatible license.

There was considerable debate about how easily the license could be changed to use later GPL versions (including version 3), and whether this change is even desirable. Torvalds himself specifically indicated upon the release of version 2.4.0 that his own code is released only under version 2. However, the terms of the GPL state that if no version is specified, then any version may be used, and Alan Cox pointed out that very few other Linux contributors had specified a particular version of the GPL.

In September 2006, a survey of 29 key kernel programmers indicated that 28 preferred GPLv2 to the then-current GPLv3 draft. Torvalds commented, "I think a number of outsiders... believed that I personally was just the odd man out because I've been so publicly not a huge fan of the GPLv3." This group of high-profile kernel developers, including Torvalds, Greg Kroah-Hartman and Andrew Morton, commented on mass media about their objections to the GPLv3. They referred to clauses regarding DRM/tivoization, patents, "additional restrictions" and warned a Balkanisation of the "Open Source Universe" by the GPLv3. Torvalds, who decided not to adopt the GPLv3 for the Linux kernel, reiterated his criticism even years later.

Loadable kernel modules

It is debated whether some loadable kernel modules (LKMs) are to be considered derivative works under copyright law, and thereby whether or not they fall under the terms of the GPL.

In accordance with the license rules, LKMs using only a public subset of the kernel interfaces are non-derived works, thus Linux gives system administrators the mechanisms to load out-of-tree binary objects into the kernel address space.

Существуют некоторые загружаемые вне дерева модули, которые законно используют функцию ядра dma_buf . GPL compliant code can certainly use it. However, a different possible use case would be Nvidia Optimus that pairs a fast GPU with an Intel integrated GPU, where the Nvidia GPU writes into the Intel framebuffer when it is active. But, Nvidia cannot use this infrastructure because it necessitates bypassing a rule that can only be used by LKMs that are also GPL. Alan Cox replied on LKML, rejecting a request from one of Nvidia's engineers to remove this technical enforcement from the API. Торвальдс четко заявил в LKML, что «[я] заявляю, что модули ядра, состоящие только из двоичных файлов, ЯВЛЯЮТСЯ производными «по умолчанию»».

С другой стороны, Торвальдс также сказал, что «[одна] серая зона, в частности, представляет собой что-то вроде драйвера, который изначально был написан для другой операционной системы (т. е. явно не является производной версией Linux). ЭТО серая зона. , и _это_ - это область, в которой я лично считаю, что некоторые модули можно считать не производными просто потому, что они не были разработаны для Linux и не зависят от какого-либо особого поведения Linux». проприетарные В частности, активно обсуждаются графические драйверы.

Всякий раз, когда в Linux загружаются проприетарные модули, ядро ​​помечает себя как «испорченное». и поэтому отчеты об ошибках из испорченных ядер часто игнорируются разработчиками.

Бинарные файлы прошивки

Официальное ядро, то есть ветка Linus git в репозитории kernel.org, содержит двоичные объекты, выпущенные в соответствии с условиями лицензии GNU GPLv2. Linux также может выполнять поиск в файловых системах в поисках двоичных объектов, проприетарного встроенного ПО, драйверов или других исполняемых модулей, а затем загружать и связывать их в пространство ядра.

Когда это необходимо (например, для доступа к загрузочным устройствам или для повышения скорости), прошивка может быть встроена в ядро, это означает встраивание прошивки в vmlinux ; однако это не всегда приемлемый вариант по техническим или юридическим вопросам (например, не разрешается делать это с прошивкой, не совместимой с GPL, хотя, тем не менее, это довольно распространено).

Торговая марка

Linux является зарегистрированной торговой маркой Линуса Торвальдса в США, Европейском Союзе и некоторых других странах. Судебная тяжба по поводу товарного знака началась в 1996 году, когда Уильям Делла Кроче, юрист, никогда не занимавшийся разработкой Linux, начал требовать лицензионные сборы за использование слова Linux . После того, как было доказано, что это слово широко использовалось задолго до того, как Делла Кроче заявил о первом использовании, товарный знак был передан Торвальдсу.

См. также

• Микроядро — ядро, предоставляющее меньше служб, чем традиционное ядро.
• История версий ядра Linux — история версий ядра Linux.
• Сравнение операционных систем
• Сравнение ядер операционных систем
• Linux — семейство Unix-подобных операционных систем.
• Minix 3 – Unix-подобная операционная система.
• macOS – операционная система для компьютеров Apple.
• Microsoft Windows – Компьютерные операционные системы

Дальнейшее чтение

• Торвальдс, Линус; Даймонд, Дэвид (2001). Просто для развлечения: история случайного революционера . ХарперБизнес . ISBN  978-0066620732 .
• Безруков Николай. «Глава 4: Доброжелательный диктатор» . Портреты пионеров открытого исходного кода (электронная книга). Мягкая панорама. Архивировано из оригинала 13 октября 2005 года . Проверено 3 октября 2005 г.
• «LinkSys и бинарные модули» . Еженедельное издание LWN.net. 16 октября 2003 г. Архивировано из оригинала 1 августа 2016 г. Проверено 21 июля 2016 г.
• «Всеобщий любимый талисман Linux» . Архивировано из оригинала 16 августа 2005 года . Проверено 16 июня 2005 г.
• Праневич, Джозеф (декабрь 2003 г.). «Чудесный мир Linux 2.6» . Архивировано из оригинала 16 июля 2003 года.
• «Изменения Linux» . Архивировано из оригинала 31 октября 2005 года . Проверено 31 октября 2005 г.
• «Семинар по ядру Linux 2.6» . Архивировано из оригинала 2 февраля 2007 года.
• «Драйверы устройств Linux» (3-е изд.). Архивировано из оригинала 27 июля 2016 года . Проверено 21 июля 2016 г.
• «Понимание ядра Linux» (книга) (3-е изд.). Архивировано из оригинала 17 декабря 2005 года . Проверено 22 декабря 2005 г.
• Сеть ядра Linux, Рами Розен, 2014 г. (книга). Архивировано из оригинала 12 мая 2015 года . Проверено 14 июня 2015 г.
• «Linux: GPL и бинарные модули» . Архивировано из оригинала 23 июля 2005 года.
• «Анатомия ядра Linux» . ИБМ . Архивировано из оригинала 27 июня 2007 года . Проверено 9 июня 2007 г.
• Таненбаум, Эндрю; Бос, Герберт (2015). Современные операционные системы . Соединенные Штаты Америки: Пирсон. п. 722. ИСБН  9781292061429 . OCLC   892574803 .

Внешние ссылки

• Официальный сайт
  • Указатель документации ядра Linux
  • Справочные страницы ядра Linux
  • Kernel bugzilla и регрессии для каждой последней версии ядра
• Kernel Newbies — источник различной информации, связанной с ядром.
• Освещение ядра на LWN.net , авторитетном источнике информации, связанной с ядром.
• Bootlin's Elixir Cross Referencer , перекрестная ссылка на исходный код ядра Linux.
• Грег Кроа Хартман о ядре Linux на YouTube