На чем написано ядро linux

Обновлено: 04.07.2024

Версии

Нумерация версий

Сначала версии нумеровались 0.01, 0.02, 0.03, . и до 1.0.

Затем начали использовать схему a.b.c (от версии 1.0 до версии 2.6). a — версия ядра, b — мажорная ревизия, c — минорная ревизия. Первое число изменялось при очень крупных переработках концепции ядра. Это было дважды в истории: в 1994 (version 1.0) и в 1996 (version 2.0). Чётность числа b определяла стабильность ядра: нечётные числа — разработческие версии, чётные числа — стабильные версии (например 1.2, 2.4 или 2.6). Минорная версия c увеличивалась при фиксах багов и при исправлениях в безопасности.

В 2004 г. после релиза 2.6.0 схема нумерации версий поменялась. Префикс 2.6 сохранялся в течение семи лет, последняя цифра увеличивалась с каждым релизом раз в два-три месяца. Иногда при срочных фиксах добавлялось четвёртое число (2.6.8.1). Чётно-нечётная схема упразднена. Разработческие версии имеют суффикс -rc.

Версия 3.0, выпущенная в 2011 г., не имела каких-то серьёзных изменений концепции. Следовала после версии 2.6.39. Считается, что Линус так решил, потому что число стало слишком большим, и чтобы заодно отметить 20-летие Linux.

Затем релизы продолжили идти по времени, но с увеличением уже второй цифры, а не третьей.

После 3.19 выпустили версию 4.0 (в 2015 г.). Затем после 4.20 вышла версия 5.0 (в марте 2019 г.). Переход к новым мажорным версиям тут не был связан с какими-то революционными изменениями. Линусу не нравятся большие номера версий. "I'm once more close to running out of fingers and toes," говорил Торвальдс.

По состоянию на 6 апреля 2020 г. последней стабильной версией ядра является версия 5.6.2.

Разработка

Код написан в основном на C с некоторыми расширениями gcc и на ассемблере (с использованием AT&T-синтаксиса GNU Assembler). Из-за наличия нестандартных хаков долгое время С-код собирался только компилятором GCC. Большим достижением для разработчиков альтернативного компилятора Clang стало то, что в 2019 году версия Clang 9.0 смогла наконец собрать всё ядро Linux под x86-64 без дополнительных патчей.

Изначально в разработке не использовалась автоматизированная система контроля версий из-за нелюбви Линуса к таким системам. В 2002 г. начали использовать BitKeeper, но это была коммерческая система. В 2005 г. Торвальдс и команда за две недели написали новую систему контроля версий — git.

Узнать версию ядра

Архитектура ядра Linux

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

Сам термин «монолит» говорит о том, что в ядре сконцентрировано всё, и, по логике, ничего не может в него добавляться или удаляться. В отличие от обычных монолитных ядер, драйверы устройств легко собираются в виде модулей и загружаются или выгружаются во время работы системы.

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

Файлы и форматы

vmlinux

Это статически слинкованный исполняемый файл, содержащий ядро Linux в одном из поддерживаемых форматов (ELF, COFF или a.out).

Название vmlinux сложилось исторически. Традиционно в Unix образ ядра назывался unix. Префикс vm значит Virtual Memory.

Традиционно лежит в корне ФС. "Сырой" vmlinux может быть полезен при отладке.

vmlinux.bin

Можно встретить на некоторых системах. То же самое, но без символов и информации для релокации.

vmlinuz

Образ ядра обычно сжимают. Одна из причин — экономия места на диске (актуально для embedded). На некоторых системах I/O происходит медленнее, чем декомпрессия при помощи CPU меньшего объёма прочитанных с диска сжатых данных (вероятно, неактуально для SSD). В прошлом на размер накладывались жёсткие ограничения (невозможность адресовать диск далее 1024 цилиндра при загрузке).

Традиционное название файла — vmlinuz.

bzImage

Это формат образа (big zImage). Был разработан для того, чтобы преодолеть ограничения на размер адресуемых данных при загрузке на разных архитектурах.

Название может ввести в заблуждение. Этот образ не обязательно сжимается при помощи bzip2, может быть и другой алгоритм.

После компиляции ядра получается файл с именем bzImage, его обычно размещают для загрузки под именем vmlinuz:

System.map

System.map — файл, внутри которого находится символьная таблица адресов функций и процедур, используемых ядром. В этой таблице перечислены имена переменных и функций и их адреса в памяти компьютера. Эта таблица весьма полезна при отладке ядра в случае Kernel panic или Linux oops. System.map генерируется при компиляции ядра.

Initial RAM Disk

Initrd (сокращение от англ. Initial RAM Disk, диск в оперативной памяти для начальной инициализации) — временная файловая система, используемая ядром Linux при начальной загрузке. Initrd обычно используется для начальной инициализации перед монтированием «настоящих» файловых систем. В Linux Kernel HOWTO (руководстве о сборке ядра) пишут, что initrd призван решить проблему курицы и яйца для модульного ядра: для монтирования файловой системы необходим модуль для работы с диском и файловой системой, а для чтения модуля необходима файловая система, с которой этот модуль читается.

Зачем нужно

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

К тому же корневая ФС может быть на томе программного RAID, LVM, даже на NFS (для бездисковых машин).

initrd

  • A ramdev block device is created. It is a ram-based block device, that is a simulated hard disk that uses memory instead of physical disks.
  • The initrd file is read and unzipped into the device, as if you did zcat initrd | dd of=/dev/ram0 or something similar.
  • The initrd contains an image of a filesystem, so now you can mount the filesystem as usual: mount /dev/ram0 /root. Naturally, filesystems need a driver, so if you use ext2, the ext2 driver has to be compiled in-kernel.
  • Done!

initramfs

В ядре Linux 2.6 появилась новая концепция загрузочного диска — он представляет собой сжатый gzip'ом cpio-архив.

cpio (copy in and out) — архиватор и формат файла, похожий на tar. Не уменьшает объём данных, просто соединяет несколько файлов в один.

  • A tmpfs is mounted: mount -t tmpfs nodev /root. The tmpfs doesn't need a driver, it is always on-kernel. No device needed, no additional drivers.
  • The initramfs is uncompressed directly into this new filesystem: zcat initramfs | cpio -i, or similar.
  • Done!

Посмотреть внутрь

Модули ядра

Модули хранятся в каталоге "/lib/modules/<версия ядра>" в виде файлов с расширением «ko». Для получения списка всех модулей из дерева можно выполнить команду поиска всех файлов с расширением «ko» в каталоге с модулями текущего ядра:

Более детальную информацию о модуле можно получить при помощи команды modinfo:

Загрузить модуль в ядро можно при помощи двух команд: «insmod» и «modprobe», отличающихся друг от друга возможностью просчета и удовлетворения зависимостей.

  1. Команда insmod загружает конкретный файл с расширением «ko», при этом, если модуль зависит от других модулей, еще не загруженных в ядро, команда выдаст ошибку, и не загрузит модуль.
  2. Команда modprobe работает только с деревом модулей, и возможна загрузка только оттуда по имени модуля, а не по имени файла.

Отсюда следует область применения этих команд: при помощи insmod подгружается файл модуля из произвольного места файловой системы (например, пользователь скомпилировал модули и перед переносом в дерево ядра решил проверить его работоспособность), а modprobe — для подгрузки уже готовых модулей, включенных в дерево модулей текущей версии ядра.

После загрузки модуля можно проверить его наличие в списке загруженных в ядро модулей при помощи команды lsmod:

Чтобы его выгрузить, можно воспользоваться командой rmmod или той же командой modprobe с ключом -r. В качестве параметра обоим командам нужно передать только имя модуля. Если модуль не используется, то он будет выгружен, а если используется — будет выдана ошибка, и придется выгружать все модули, которые от него зависят.

Автоматизация

В современных ядрах при подключении оборудования модули подключаются автоматически, а это событие обрабатывается демоном udev, который создает соответствующий файл устройства в каталоге /dev. Все это выполняется в том случае, если соответствующий модуль корректно установлен в дерево модулей. В случае с файловыми системами ситуация та же: при попытке монтирования файловой системы ядро подгружает необходимый модуль автоматически, и выполняет монтирование. Если необходимость в модуле не на столько очевидна, ядро его не загружает самостоятельно. Например, для поддержки функции шифрования на loop устройстве нужно вручную подгрузить модуль «cryptoloop», а для непосредственного шифрования — модуль алгоритма шифрования, например «blowfish».

Для автоматической загрузки модулей в разных дистрибутивах предусмотрены разные механизмы. B Ubuntu — редактируем файл /etc/modules [1].

- Можно ли под ядро писать модули на Си и на С++, или только на каком-то одном языке?




> - На чём написано ядро Линукс, на Си или C++?

> - Можно ли под ядро писать модули на Си и на С++

Можно - но заколебешься.

На самом деле, тот кто задает такие вопросы мягко говоря не готов для того, чтобы писать модули, да еще и на C++ :-)

>- На чём написано ядро Линукс, на Си или C++?

>- Можно ли под ядро писать модули на Си и на С++, или только на каком-то одном языке?

Модули можно писать на чем-угодно, если только компилятор создает корректный с точки зрения ядра код. Даже компилятор С теоретически можно создавать неприемлемый для ядра код.


Для каких целей используется в ядре ASM?


Т.е. для kernel programmera необходимо знание Си и ассемблера или только Си? С++ нужен?

В сети можно какую нить литературку по программированию ядра можно найти?


в моём больном сознании не совмещаются начинания по "программированию ядра" и не желание посмотреть для начала _самому_ сорцы этого самого ядра: определить язык по сорцам не так уж и сложно ;)

ЗЫ. не надо рассказывать про дороговизну интернета


>не надо рассказывать про дороговизну интернета

Последняя з/п уже истрачена на пиво и до конца февраля не имею возможности скачать :)))


>з/п уже истрачена на пиво

да-да, зарпалту грех не пропить


>Как-то странно человек, не разу не ставивший linux, хочет писать под него модули?

Успокойтесь уважаемый, ставивший и не раз, и есть дистры без сорцов ядра. В данный момент жду из линуксцентра Suse 10.2, а пока не имею возможности ни скачать сорцы, ни в дистре посмотреть.

> и есть дистры без сорцов ядра.

AltLinux Home -- вроде так назыввался
Вообще и без сорцев и средств разработки :)

>AltLinux Home -- вроде так назыввался Вообще и без сорцев и средств разработки :)

Это с трудом можно назвать дистрибутив. Ты бы еще Damm Small привел в пример.



> В сети можно какую нить литературку по программированию ядра можно найти?

плюсы в ядре нафиг не нужны
не место им в ядре
если вы хотите заточить свое знание ооп ,идите куда подальше от ядра :-)
ядро-это код,где в течение 15 лет отшлифовывается буквально каждая машинная команда для того,чтобы ядро было максимально минимизировано по размеру и максимально оптимизировано по скорости и надежности


2. Ооп там и так есть, просто костыльный. Ни что не мешает на C++ писать вменяемый код. По скорости разница будет максимум проценты.

По слухам из глубокой древности, древний гуру и джедай Торвалд-сан начал писать ядро Матрицы нового поколения на голом С и асме. Но с течением времени из-за притока неофитов, для предотвращения искажения Истины подлинные и непроявленные сорцы ядра превратились в сакральный текст на brainfuck. И задачу трансляции в понятный для Гуру вид и обратно выполняет когорта девелоперов, организованных в сектоподобный конгломерат, результатой деятельности которых являются зловещие заклинания под названием "патчи", преобразующие реальность и счётчик в версии ядре.

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


я тебя обрадую -- ооп в ядре есть, хоть и на Си :)


А может и правда - пофлеймим?

> если вы хотите заточить свое знание ооп ,идите куда подальше от ядра :-)

Ядро широко использует ООП (правда, в угребищном Си-варианте)

> ядро-это код,где в течение 15 лет отшлифовывается буквально каждая машинная команда

Аха, ядро включает в себя специальный компилятор, который спрашивает у хакера, какие именно команды выдавать :)

>>ха, ядро включает в себя специальный компилятор, который спрашивает у хакера, какие именно команды выдавать

аха
компилятор в таких случаях вообще не спрашивают
инлайн в таких случаях пользуют

Хронология разработки ядра Linux очень обширна, однако точно прослеживаются истоки его создания, которые ведут к UNIX. В 1969 году Кен Томпсон из исследовательской группы Bell Laboratories совместно с Деннисом Ритчи на передовом микро-компьютере PDP-7 разработал ядро многозадачной, многопользовательской операционной системы UNICS ( позже переименованной в UNIX-TP). В момент создания ядра UNIX-TP Ритчи находился под влиянием своего прошлого проекта - ОС MULTICS, несмотря на наличие достаточно инновационных и передовых идей, таких как: строго сегментированная модель данных, сегментно-страничная виртуальная память, динамическое связывание, переконфигурация всей системы «на ходу», иерархическая файловая система, впервые реализованный подход с использованием стеков для каждого вычислительного процесса внутри системы ядра и др; проект был закрыт ввиду сложной архитектуры ОС, а также из-за недостатков, связанных с распределением памяти файлов, больших по размеру чем установленный системный лимит. Стоит также заметить, что вся операционная система, включая сложный компилятор языка PL/I, пользовательские команды и дополнительные библиотеки, состояла из примерно полутора тысяч исходных файлов, каждый из которых содержал примерно по 200 строк кода. В скомпилированном виде весь этот код занимал около 4,5 Мегабайт, что было огромным размером по тем временам. Компиляторы Multics в основном оптимизировали код по размеру, а не по эффективности использования центрального процессора, что было обосновано стремлением к экономии памяти в многопользовательской системе.

Несмотря на неудачу своего предшественника, UNIX вобрал в себя концепцию MULTICS и был детально проработан. Первые две версии ОС были написаны на ассемблере, однако третья и четвертая версии использовали язык, разработанный Ритчи - С [4] , архитектура третьей версии использовала встроенный компилятор языка, а четвертая представляла собой полностью переписанное на СИ системное ядро. С приходом пятой версии UNIX был полностью переписан на язык СИ. Изначально создателем он был задуман как язык необходимый в написании операционных систем. Это переписывание разрешено команде UNIX TM с целью перехода на более мощную аппаратную часть - PDP-11/45 и 11/70 компьютеры. С 1974 года UNIX стал распространяться среди университетов и академических учреждений. С 1975 года началось появление новых версий, разработанных за пределами Bell Labs, и рост популярности системы.

В 1980 году компанией AT&T был разработан пакет коммерческих лицензий на все дистрибутивы UNIX, и сведение всех версий в одну: UNIX System V. Университет Калифорнии, Беркли продолжал разрабатывать свою собственную версию Unix под названием BSD. Многие из важнейших разработок в UNIX изначально пришли из BSD, к примеру, включение TCP/IP в основную версию UNIX. Поскольку основная часть системы поставлялась в исходных текстах, написанных на языке С, опытным программистам не требовалось документации, чтобы разобраться в архитектуре UNIX. C ростом популярности микропроцессоров другие компании переносили эту операционную систему на другие платформы, но простота и ясность операционной системы искушали многих на ее расширение и последующую модификацию, в результате чего появилось много разновидностей базовой системы.

Не желая терять инициативу, AT&T в 1982 году объединила несколько существовавших версий UNIX и создала версию под названием SYSTEM |||. В отличие от редакций, предназначавшихся, в первую очередь, для внутреннего использования и не получивших дальнейшего развития, SYSTEM ||| была создана для распространения за пределами Bell Labs и AT&T и положила начало новой ветви UNIX , которая и сегодня жива и развивается.

Краткая история Linux

В 1991 году в Хельсинки, Финляндии, Линус Торвальдс начал работу над проектом, который был, по его словам, «просто для удовольствия». Этот проект в конечном счете стал ядром Linux. Он никогда не был предназначен для чего-то особенного, просто инструмент, который позволил бы студенту получить доступ к UNIX-серверам в соседнем университете. Он написал его специально для железа, на котором он работал на тот момент, и оно не зависело от операционной системы. Linux разработана "с нуля" для процессора Intel i386, сегодня она перенесена на огромный ряд других аппаратных платформ, включая серверы Alpha фирмы DEC.

Переход от Unix к Linux

Linux был разработан в попытке создать бесплатную альтернативу коммерческим UNIX-средам. Его история начинается в 1991 или даже в 1983 гг., когда был создан проект GNU, чьей исходной целью было предоставить бесплатную альтернативу UNIX. Linux работает на гораздо большем количестве платформ, например на Intel®/AMD x86. Большинство ОС UNIX способны работать только на одной платформе.У Linux и UNIX общие исторические корни, но есть и серьезные отличия. Много инструментов, утилит, и бесплатных приложений, являющихся стандартными для Linux, первоначально задумывались как бесплатная альтернатива программам для UNIX. Linux часто предоставляет поддержку множества опций и приложений, заимствуя лучшую или наиболее популярную функциональность из UNIX. Администратору или разработчику, который привык работать с Linux, система UNIX может показаться не очень удобной для использования. С другой стороны, фундамент UNIX-подобной операционной системы (инструменты, файловая система, интерфейсы API) достаточно стандартизирован.

Понятие ядра операционной системы Linux.

Ядро является сердцем любой операционной системы, обеспечивая базовую функциональность операционной системы:

  1. создает процессы и управляет ими
  2. распределяет и обеспечивает доступ к файлам, а также к периферийным устройствам

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

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

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

Все коммерческие версии UNIX в некоторой степени эволюционировали до модульного ядра. Драйверы и отдельные особенности ОС доступны как отдельные компоненты и могут быть по необходимости загружены или выгружены из ядра. Но открытая модульная архитектура Linux гораздо гибче. Однако гибкость и адаптируемость Linux означают и постоянное изменение. Исходный код Linux постоянно меняется, и, по прихоти разработчика, может поменяться API. Когда модуль или драйвер написан для коммерческой версии UNIX, он проработает гораздо дольше, чем тот же драйвер для Linux.


Устройство компонентов ядра ОС Linux

Ядро состоит из:

  1. Файловая система
  2. Подсистема управления процессами и памятью
  3. Подсистема ввода / вывода

Файловая подсистема

Файловая подсистема обеспечивает унифицированный интерфейс доступа к данным, расположенным на дисковых накопителях, а также к периферийным устройствам. Одни и те же функции open(), read(), write() могут использоваться как при чтении или записи данных на диск, так и при выводе текста на принтер или в терминал. Файловая подсистема контролирует права доступа к файлу, выполняет операции размещения и удаления файла. Поскольку большинство прикладных функций выполняется через интерфейс файловой системы, права доступа к файлам определяют привилегии пользователя в системе. Файловая подсистема обеспечивает маршрутизацию запросов периферийным устройствам, соответствующим модулям подсистемы ввода/вывода.

Подсистема управления запросами

Запущенная на выполнение программа порождает в системе один или более процессов ( задач ). Подсистема управления процессами контролирует:

  1. Создание и удаление процессов
  2. Распределение системных ресурсов ( памяти, вычислительных ресурсов ) между процессами
  3. Синхронизацию процессов
  4. Межпроцессорное взаимодействие

Известно, что в общем случае число активных процессоров превышает число процессоров компьютера, но в каждый конкретный момент времени на каждом процессоре может выполняться только один процесс. Операционная система управляет доступом процессоров к вычислительным ресурсам, создавая ощущение одновременного выполнения нескольких задач. Специальная задача ядра, называемая распорядителем или планировщиком процессов, разрешает конфликты между процессами в конкуренции за системные ресурсы ( процессор, память, периферийные устройства ). Планировщик запускает процесс на выполнение, следя за тем, чтобы процесс монопольно не захватил разделяемые системные ресурсы. Процесс освобождает процессор, ожидая длительной операции ввода/вывода, или по прошествии периода времени. В этом случае планировщик выбирает следующий процесс с наивысшим приоритетом и запускает его на выполнение. Модуль управления памятью обеспечивает размещение оперативной памяти для прикладных задач. Оперативная память является дорогостоящим ресурсом, и, как правило, она редко "простаивает". В случае, если для всех процессов недостаточно памяти, ядро перемещает части процесса или несколько процессов во вторичную память ( как правило, для этого выделена некоторая область жесткого диска ), освобождая ресурсы для действующих процессов. Все современные системы реализуют виртуальную память: процесс выполняется в собственном логическом адресном пространстве, которое может значительно превышать доступную физическую память. Управление виртуальной памятью процесса также входит в перечень задач модуля управления памятью. Модуль межпроцессного взаимодействия.отвечает за уведомление процессов о событиях с помощью сигналов и обеспечивает возможность передачи данных между различными процессами.

Подсистема ввода/вывода

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

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

Ядро Linux поддерживает многие унаследованные от UNIX особенности, такие как:

  1. многозадачность
  2. виртуальную память
  3. динамические библиотеки
  4. отложенную загрузку
  5. производительную систему управления памятью
  6. современные сетевые протоколы

На сегодняшний день Linux — монолитное ядро с поддержкой загружаемых модулей. Драйверы устройств и расширения ядра обычно запускаются в 0-м кольце защиты, с полным доступом к оборудованию. В отличие от обычных монолитных ядер, драйверы устройств легко собираются в виде модулей и загружаются или выгружаются во время работы системы, эта особенность также является унаследованной от первого предшественника - ОС Multics. То, что архитектура Linux не является микроядерной, вызвало обширнейшие споры между Линусом Торвальдсом и Эндрю Таненбаумом в конференции.

Выполнение в режиме ядра

Существуют всего три события, при которых выполнение процесса переходит в режим ядра:

  1. аппаратные прерывания
  2. особые ситуации
  3. системные вызовы

Во всех случаях ядро Linux получает управление и вызывает соответствующую системную процедуру для обработки события. Непосредственно перед вызовом ядро сохраняет состояние системы, а именно состояние прерванного процесса в системном стеке. После завершения обработки, состояние процесса восстанавливается и процесс возвращается в исходный режим выполнения. Чаще всего это режим задачи, например, когда прерывание возникло, когда процесс уже находился в режиме ядра, после обработки события он останется в том же состоянии. Стоит разграничить особые ситуации и прерывания. Аппаратные прерывания генерируются периферией при наступлении исключительных событий ( например, завершение печати или поступление данных на последовательный вход ввода ) и имеют асинхронный характер, поскольку невозможно в тот или иной момент сказать, когда система нам пробросит исключение. Часто, эти прерывания не связаны с текущим процессом, а вызваны внешними событиями. Именно поэтому, обработка прерываний происходит в системном контексте, при этом недопустим доступ к адресному пространству процесса. По этой причине обработка ситуаций не должна блокироваться, поскольку это вызовет блокирование выполнения независимого процесса Системные вызовы позволяют процессам воспользоваться базовыми услугами ядра. Интерфейс системных вызовов определяет ограниченный набор точек входа в ядро системы, обращение к которым изменяет режим выполнения процесса и позволяет выполнять привилегированные функции ядра. Стандартная библиотека C, позволяющая использовать системные функции как обычные процедуры, на самом деле содержит заглушки, обеспечивающие фактическую реализацию вызова соответствующей точки входа ядра. Эта реализация практически не зависит от аппаратной части системы. Например, для систем на базе процессоров Intel используются шлюзы. Имеются два типа шлюзов: шлюзы ловушек и шлюзы вызовов. Для осуществления вызова через шлюз ловушки процесс выполняет команду прерывания, а при работе через шлюз вызова - команду межсегментного вызова. Выполнение системного вызова происходит в режиме ядра, но в контексте процесса, сделавшего системный вызов. Таким образом, открыт доступ к адресному пространству процесса и используется стек ядра процесса.

Примечания

Литература

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

Так что же такое ядро ОС и каковы его функции? Как известно, компьютер – не только система аппаратного обеспечения (железа), но и набор работающего на нем программного обеспечения. Чтобы второе могло эффективно работать на первом, нужна более низкоуровневая программа, скрывающая сложности работы с железом и предоставляющая обычным программам и пользователям удобный для них интерфейс.

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

Представим себе, что ядра нет, а каждая запущенная программа сама обращается к железу и обрабатывает сигналы от него. Вроде бы ничего страшного, кроме дублирования кода в каждой такой программе. Но на компьютере одновременно работает множество программ. Как они будут "договариваться" между собой о совместном использовании общего аппаратного обеспечения?

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

Ядро операционной системы – это тоже программа, написанная на том или ином языке программирования и скомпилированная в исполняемый файл. Однако, в отличии от других программ, ядро всегда загружается первым и потом постоянно "сидит" в определенной области оперативной памяти. То есть это программа, которая всегда находится в запущенном состоянии и взаимодействует, с одной стороны, с железом, а с другой – с системными и пользовательскими программами.

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

Выделяют операционные системы на монолитном ядре и микроядре, а также разные промежуточные варианты. Монолитное ядро проще и быстрее работает, так как в памяти всегда находится почти весь код. Микроядро меньше, сложнее, работает медленнее, однако нередко считается более передовым из-за легкости подключения новых частей кода. Микроядро, находясь в памяти, организует взаимодействие между другими частями кода операционной системы, которые являются самостоятельными программами (см. пример выше про загрузку драйверов).

Ядра Unix-подобных систем

Ядро Unix являлось первой практической реализацией новых идей и открытий 60-70-х годов XX века в области создания операционных систем.

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

В 80-х годах Unix-системы начали множится и видоизменяться. Некоторые умы вовремя спохватились и создали специальные стандарты, обеспечивающие совместимость систем. Это значит, что программа, написанная для одной Unix-подобной системы, должна работать в другой. Стандарты назвали POSIX.

Особенности ядра Linux

С технической точки зрения, Linux – это ядро, а не операционная система. Linux + программы из проекта GNU рождают операционную систему GNU/Linux. Однако ее тоже не существует в чистом виде. Разработчики дистрибутивов дорабатывают на свой лад GNU/Linux, после чего получаются различные операционные системы-дистрибутивы. У каждого дистрибутива есть собственное имя (Ubuntu, Fedora и т. п.). Однако в основе всех этих систем лежит ядро Linux, поэтому все они принадлежат одному семейству Linux-систем.

Ядро Linux начал разрабатывать в 1991 году Линус Торвальдс. В дальнейшем оно развивалось и совершенствовалось многими людьми. Ядро Linux выпускается под лицензией GNU GPL.

Ядро Linux Unix-подобно, так как заимствовало идеи, заложенные в Unix, соответствует стандартам POSIX, а также по большей части написано на языке С.

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

Ядро выпускается в виде стабильных и разрабатываемых версий. В стабильных обычно исправлены ошибки, добавлены новые драйверы устройств. До недавнего времени четное второе число в названии ядра, говорило, что оно стабильно. Нечетное число обозначало разрабатываемую нестабильную версию. В 2011 году от такого подхода к нумерации версий отказались.

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

Конфигурируют ядро с целью включения, отключения или компиляции в виде модуля какого-либо драйвера или функции. Другими словами, "ядро под себя" не будет содержать лишних драйверов для оборудования, которого нет.

Курс с ответами к заданиям и дополнительными уроками:
android-приложение, pdf-версия.

Читайте также: