Написать операционную систему. Как создать свою систему для любой деятельности

На вопрос Как создать свою ОС? заданный автором расспросить лучший ответ это Идея похвальная.
Прежде всего нужно знать систему команд машины, для которой намереваешься писать ОС.
Система команд находит свое прямое отражение в языке ассемблера.
Поэтому в первую очередь нужно придумать свой язык ассемблера и написать для него программу (ассемблер) , транслирующий буквенно-цифровую символику в машинный
код.
Если интересно, то можно посмотреть, какими бы требования должна обладать новая (идеальная) ОС.
Некоторые такие черты перечислены тут:
.ru/D_OS/OS-PolyM.html#IdealOS
Необходимо изучать материалы сайтов-разработчиков микропроцессоров. Например, Intel и AMD.
Возможно, тебе будет полезен видео-курс лекций по ОС, который представлен здесь:
.ru/D_OS/OS_General.html
PS: Не слушай пессимистов. Исходи из идеологии петуха, гонящегося за курицей:
"Не догоню, хоть разогреюсь. "
Источник: Сайт "Используй ПК правильно! "

Ответ от Двутавровый [новичек]
Конечно) Тут-же одни гейтсы сидят) На майкрософте спроси)



Ответ от Приспособление [новичек]
возьми все ОС и в одну запихай


Ответ от Александр Тунцов [гуру]
Ознакомься с ОС Linux, обучись программированию и в путь


Ответ от ~In Flames~ [гуру]
Программирование учить на высшем уровне, собрать целую толпу таких же компьютерных гениев и тогда уже можно делать.


Ответ от Rasul Magomedov [гуру]
Начни с создания нескучных обоев


Ответ от Капитан Гугл [гуру]
Про "10 лет на изучение основ" - не слушай, Торвальдс первую версию Линукса написал в 22 года, а компьютер у него в 12 появился. Как ты понимаешь, он не только основы изучал.
Начни с изучения уже существующего - с одной стороны, "Современные операционные системы" Танненбаума, с другой стороны - собери Linux From Scratch, с третьей - учи Ассемблер, C, C++. За все про все - можно в 3-4 года уложиться. После этого можешь приступать к разработке своей системы... если еще захочешь.


Ответ от Ёаня Семенов [гуру]
знаешь как делал Гейтс? попробуй так же, говорят прибыльно получается..
когда его наказали родители, он от нечего делать стал прыгать попой на клаве, потом продал назвав то что получилось " windows "
п с а если реально то напиши сначала "Hello World" в С++ и сразу поймешь что идея параноидальная


Ответ от Kostafey [гуру]
А зачем? Чем принципиально не устраивают существующие? Неужели нет ни одной, хоть частично удовлетворяющей вашим требованиям к ОС? Может стоит лучше присоединиться к команде разработчиков? Толку в 100500 раз больше будет.
И потом, вы забросите эту идею еще на 0,(0)1% ее реализации.


Ответ от Евгений Ломега [гуру]
Э. Таненбаум "Операционные системы: разработка и реализация "
удачи
PS К сожалению как это делал Бил Гейтс у тебя вряд ли получится. У него мама крутая банкирша, у тебя?


Ответ от Krab Bark [гуру]
Написать простейшую ОС самому можно, но она никак не сможет конкурировать с ОС вроде Windows, MAC OS или Linux, над которыми минимум десяток лет трудились сотни или тысячи программистов. Кроме того, ОС - только фундамент. Нужно, чтобы разработчики оборудования писали для этой ОС свои драйверы, разработчики прикладных программ писали для нее редакторы, плееры, браузеры, игры, черта в ступе... А без этого ОС останется никому не нужным фундаментом для дома, который никто строить не будет.


Ответ от Вадим Стаханов [активный]
Лучше бы на филолога пошел бы учится. А потом бы кричал "Свободная касса! "


Ответ от =Serge= [гуру]
Ура! Наконец то 58 вопрос на сайте про создание "своей" ОС))
Вот вопросы про "написать свою ОС" - их только 34))
Читай....92 вопроса*10 ответов = приблизительно 920 ответов))
Заодно возможно поймешь что значат "нескучные обои")).


Ответ от Irreproducible [гуру]
еще один Денис Попов с очередным BolgenOS"ом?


Ответ от Иван татарчук [новичек]
запусти блокнот скачай компилятор жабаскрипт и начни прыгать попой по клавиатуре
через 60мин компилируй и все
твоя оска готова

Книга «Операционная система с 0 до 1» опубликована на GitHub и имеет более 2 000 звездочек и 100 форков. Как понятно из названия, прочитав её, вы сможете создать свою собственную операционную систему - и, пожалуй, мало что в мире программистов может быть круче.

Благодаря этой книге вы научитесь следующему:

  • Узнаете, как создать операционную систему на основе технической документации железа. В реальном мире это так и работает, вы не сможете использовать Google для быстрых ответов.
  • Поймёте, как компьютерные компоненты взаимодействуют друг с другом, от софта к железу.
  • Научитесь писать код самостоятельно. Слепое копирование кода не есть обучение, вы действительно научитесь решать проблемы. Кстати, слепое копирование еще и опасно.
  • Освоите всем привычные инструменты для низкоуровневой разработки.
  • Познакомитесь с языком ассемблера.
  • Выясните, из чего состоят программы и как операционная система запускает их. Небольшой обзор этой темы для любознательных мы давали в .
  • Разберётесь, как проводить отладку программы прямо на железе с GDB и QEMU.
  • Язык программирования C. Быстро освоить его можно, следуя .
  • Базовые знания Linux. Достаточно изучить на нашем сайте.
  • Базовые знания в физике: атомы, электроны, протоны, нейтроны, напряжение.
  • Закон Ома о соотношении напряжения, силы тока и сопротивления.

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

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

Каждый решает проблему обучения по-своему. Кто-то читает много литературы, кто-то старается поскорее перейти к практике и разбираться по ходу дела, кто-то пытается объяснять друзьям всё, что сам изучает. А мы решили совместить эти подходы. Итак, в этом курсе статей мы будем шаг за шагом демонстрировать, как пишется простая операционная система. Статьи будут носить обзорный характер, то есть в них не будет исчерпывающих теоретических сведений, однако мы будем всегда стараться предоставить ссылки на хорошие теоретические материалы и ответить на все возникающие вопросы. Чёткого плана у нас нет, так что многие важные решения будут приниматься по ходу дела, с учётом ваших отзывов.

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

Мы будем предполагать, что читатель уже знаком с основами языков ассемблер и Си, а также элементарными понятиями архитектуры ЭВМ. То есть, мы не будем объяснять, что такое регистр или, скажем, оперативная память. Если вам не будет хватать знаний, вы всегда можете обратиться к дополнительной литературе. Краткий список литературы и ссылки на сайты с хорошими статьями есть в конце статьи. Также желательно уметь пользоваться Linux, так как все инструкции по компиляции будут приводиться именно для этой системы.

А теперь - ближе к делу. В оставшейся части статьи мы с вами напишем классическую программу «Hello World». Наш хеллоуворлд получится немного специфическим. Он будет запускаться не из какой-либо операционной системы, а напрямую, так сказать «на голом железе». Перед тем, как приступить непосредственно к написанию кода, давайте разберёмся, как же конкретно мы пытаемся это сделать. А для этого надо рассмотреть процесс загрузки компьютера.

Итак, берем свой любимый компьютер и нажимаем самую большую кнопочку на системном блоке. Видим веселую заставку, системный блок радостно пищит спикером и через какое-то время загружается операционная система. Как вы понимаете, операционная система хранится на жёстком диске, и вот тут возникает вопрос: а каким же волшебным образом операционная система загрузилась в ОЗУ и начала выполняться?

Знайте же: за это отвечает система, которая есть на любом компьютере, и имя ей - нет, не Windows, типун вам на язык - называется она BIOS. Расшифровывается ее название как Basic Input-Output System, то есть базовая система ввода-вывода. Находится BIOS на маленькой микросхемке на материнской плате и запускается сразу после нажатия большой кнопки ВКЛ. У BIOS три главных задачи:

  1. Обнаружить все подключенные устройства (процессор, клавиатуру, монитор, оперативную память, видеокарту, голову, руки, крылья, ноги и хвосты…) и проверить их на работоспособность. Отвечает за это программа POST (Power On Self Test – самотестирование при нажатии ВКЛ). Если жизненно важное железо не обнаружено, то никакой софт помочь не сможет, и на этом месте системный динамик пропищит что-нибудь зловещее и до ОС дело вообще не дойдет. Не будем о печальном, предположим, что у нас есть полностью рабочий компьютер, возрадуемся и перейдем к рассмотрению второй функции BIOS:
  2. Предоставление операционной системе базового набора функций для работы с железом. Например, через функции BIOS можно вывести текст на экране или считать данные с клавиатуры. Потому она и называется базовой системой ввода-вывода. Обычно операционная система получает доступ к этим функциям посредством прерываний.
  3. Запуск загрузчика операционной системы. При этом, как правило, считывается загрузочный сектор - первый сектор носителя информации (дискета, жесткий диск, компакт-диск, флэшка). Порядок опроса носителей можно задать в BIOS SETUP. В загрузочном секторе содержится программа, иногда называемая первичным загрузчиком. Грубо говоря, задача загрузчика - начать запуск операционной системы. Процесс загрузки операционной системы может быть весьма специфичен и сильно зависит от её особенностей. Поэтому первичный загрузчик пишется непосредственно разработчиками ОС и при установке записывается в загрузочный сектор. В момент запуска загрузчика процессор находится в реальном режиме.
Печальная новость: размер начального загрузчика должен быть всего 512 байт. Почему так мало? Для этого нам надо ознакомиться с устройством дискеты. Вот познавательная картинка:

На картинке изображена поверхность дискового накопителя. У дискеты 2 поверхности. На каждой поверхности есть кольцеобразные дорожки (треки). Каждый трек делится на маленькие дугообразные кусочки, называемые секторами. Так вот, исторически сложилось, что сектор дискеты имеет размер 512 байт. Самый первый сектор на диске, загрузочный сектор, читается BIOS"ом в нулевой сегмент памяти по смещению 0x7С00, и дальше по этому адресу передается управление. Начальный загрузчик обычно загружает в память не саму ОС, а другую программу-загрузчик, хранящуюся на диске, но по каким-то причинам (скорее всего, эта причина - размер) не влезающую в один сектор. А поскольку пока что роль нашей ОС выполняет банальный хеллоуворлд, наша главная цель - заставить компьютер поверить в существование нашей ОС, пусть даже и на одном секторе, и запустить её.

Как устроен загрузочный сектор? На PC единственное требование к загрузочному сектору - это содержание в двух его последних байтах значений 0x55 и 0xAA - сигнатуры загрузочного сектора. Итак, уже более-менее понятно, что нам нужно делать. Давайте же писать код! Приведённый код написан для ассемблера yasm .

section . text

use16

org 0x7C00 ; наша программа загружается по адресу 0x7C00

start:

mov ax , cs

mov ds , ax ; выбираем сегмент данных



mov si , message

cld ; направление для строковых команд

mov ah , 0x0E ; номер функции BIOS

mov bh , 0x00 ; страница видеопамяти

puts_loop:

lodsb ; загружаем очередной символ в al

test al , al ; нулевой символ означает конец строки

jz puts_loop_exit

int 0x10 ; вызываем функцию BIOS

jmp puts_loop

puts_loop_exit:

jmp $ ; вечный цикл



message:

db "Hello World!" , 0

finish:

times 0x1FE - finish+ start db 0

db 0x55 , 0xAA ; сигнатура загрузочного сектора

Эта короткая программа требует ряда важных пояснений. Строка org 0x7C00 нужна для того, чтобы ассемблер (имеется в виду программа, а не язык) правильно рассчитал адреса для меток и переменных (puts_loop, puts_loop_exit, message). Вот мы ему и сообщаем, что программа будет загружена в память по адресу 0x7C00.
В строках
mov ax , cs

mov ds , ax
происходит установка сегмента данных (ds) равным сегменту кода (cs), поскольку в нашей программе и данные, и код хранятся в одном сегменте.

Далее в цикле посимвольно выводится сообщение «Hello World!». Для этого используется функция 0x0E прерывания 0x10 . Она имеет следующие параметры:
AH = 0x0E (номер функции)
BH = номер видеостраницы (пока не заморачиваемся, указываем 0)
AL = ASCII-код символа

В строке « jmp $ » программа зависает. И правильно, незачем ей выполнять лишний код. Однако чтобы компьютер опять заработал, придется перезагрузиться.

В строке « times 0x1FE-finish+start db 0 » производится заполнение остатка кода программы (за исключением последних двух байт) нулями. Делается это для того, чтобы после компиляции в последних двух байтах программы оказалась сигнатура загрузочного сектора.

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

Читая Хабр в течении последних двух лет, я видел только несколько попыток разработки ОС (если конкретно: от пользователей и (отложено на неопределённый срок) и (не заброшено, но пока больше походит на описание работы защищённого режима x86-совместимых процессоров, что бесспорно тоже необходимо знать для написания ОС под x86); и описание готовой системы от (правда не с нуля, хотя в этом нет ничего плохого, может даже наоборот)). Мне почему-то думается, что почти все системные (да и часть прикладных) программисты хотя бы раз, но задумывались о написании собственной операционной системы. В связи с чем, 3 ОС от многочисленного сообщества данного ресурса кажется смешным числом. Видимо, большинство задумывающихся о собственной ОС так никуда дальше идеи и не идёт, малая часть останавливается после написания загрузчика, немногие пишут куски ядра, и только безнадёжно упёртые создают что-то отдалённо напоминающее ОС (если сравнивать с чем-то вроде Windows/Linux). Причин для этого можно найти много, но главной на мой взгляд является то, что люди бросают разработку (некоторые даже не успев начать) из-за небольшого количества описаний самого процесса написания и отладки ОС, который довольно сильно отличается от того, что происходит при разработке прикладного ПО.

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

Как не надо начинать
Просьба не воспринимать следующий ниже текст как явную критику чьих-то статей или руководств по написанию ОС. Просто слишком часто в подобных статьях под громкими заголовками акцент делается на реализации какой-то минимальной заготовки, а подаётся она как прототип ядра. На самом деле следует задумываться о структуре ядра и взаимодействии частей ОС в целом, а тот прототип рассматривать как стандартное «Hello, World!»-приложение в мире прикладного ПО. В качестве небольшого оправдания этих замечаний, следует сказать, что ниже есть подраздел «Hello, World!», которому в данном случае уделено ровно столько внимания сколько нужно, и не больше.

Не надо писать загрузчик. Умные люди придумали Multiboot Specification , реализовали и подробно описали, что это такое и как его использовать. Не хочу повторяться, просто скажу, что это работает, облегчает жизнь, и его надо применять. Спецификацию, кстати, лучше прочесть полностью, она небольшая и даже содержит примеры.

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

Не надо загружать кастомный шрифт в видео память и выводить что-либо на русском. Толку от этого никакого. Гораздо проще и универсальнее использовать английский, а изменение шрифта оставить на потом, загружая его с жёсткого диска через драйвер файловой системы (заодно будет дополнительный стимул сделать больше, чем просто начать).

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

После начального ликбеза необходимо определиться с главными вопросами:

  • целевая архитектура - x86 (real/protected/long mode), PowerPC, ARM, ...
  • архитектура ядра/ОС - монолит, модульный монолит, микроядро, экзоядро, разные гибриды
  • язык и его компилятор - C, C++, ...
  • формат файла ядра - elf, a.out, coff, binary, ...
  • среда разработки (да, это тоже играет не последнюю роль) - IDE, vim, emacs, ...
Далее следует углублять знания согласно выбранному и по следующим направлениям:
  • видео память и работа с ней - вывод в качестве доказательства работы необходим с самого начала
  • HAL (Hardware Abstraction layer) - даже если поддержка нескольких аппаратных архитектур и не планируется грамотное отделение самых низкоуровневых частей ядра от реализации таких абстрактных вещей как процессы, семафоры и так далее лишним не будет
  • управление памятью - физической и виртуальной
  • управление исполнением - процессы и потоки, их планирование
  • управление устройствами - драйвера
  • виртуальные файловые системы - для обеспечения единого интерфейса к содержимому различных ФС
  • API (Application Programming Interface) - как именно приложения будут обращаться к ядру
  • IPC (Interprocess Communication) - рано или поздно процессам придется взаимодействовать
Инструменты
Учитывая выбранные язык и средства разработки следует подобрать такой набор утилит и их настроек, которые в будущем позволят путём написания скриптов, максимально облегчить и ускорить сборку, подготовку образа и запуск виртуальной машины с проектом. Остановимся немного детальнее на каждом из этих пунктов:
  • для сборки подойдут любые стандартные средства, как то make, cmake,… Тут в ход могут пойти скрипты для линкера и (специально написанные) утилиты для добавления Multiboot-заголовка, контрольных сумм или для каких-либо других целей.
  • под подготовкой образа имеется ввиду его монтирование и копирование файлов. Соответственно, формат файла образа надо подбирать так, чтобы его поддерживала как утилита монтирования/копирования, так и виртуальная машина. Естественно, никто не запрещает совершать действия из этого пункта либо как финальную часть сборки, либо как подготовку к запуску эмулятора. Всё зависит от конкретных средств и выбранных вариантов их использования.
  • запуск виртуальной машины труда не представляет, но нужно не забыть сначала отмонтировать образ (отмонтирование в этом пункте, так как до запуска виртуальной машины реального смысла в этой операции нет). Также не лишним будет скрипт для запуска эмулятора в отладочном режиме (если таковой имеется).
Если все предыдущие шаги выполнены, следует написать минимальную программу, которая будет загружаться как ядро и выводить что-нибудь на экран. В случае обнаружения неудобств или недостатков выбранных средств, необходимо их (недостатки) устранить, ну или, в худшем случае, принять как данность.

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

После того как этот этап прошёл успешно, начинается настоящая разработка.

Обеспечение run-time поддержки
Так как предлагается писать на языках высокого уровня, следует позаботиться об обеспечении поддержки части средств языка, которые обычно реализуются авторами пакета компилятора. Например для C++, сюда относятся:
  • функция для динамического выделения блока данных на стеке
  • работа с heap
  • функция копирования блока данных (memcpy)
  • функция-точка входа в программу
  • вызовы конструкторов и деструкторов глобальных объектов
  • ряд функций для работы с исключениями
  • стаб для нереализованных чисто-виртуальных функций
При написании «Hello, World!» отсутствие этих функций может никак не дать о себе знать, но по мере добавления кода, линкер начнёт жаловаться на неудовлетворённые зависимости.

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

Отладка
Не смотрите, что об отладке говорится ближе к концу статьи. На самом деле это очень серьёзный и непростой вопрос в разработке ОС, так как обычные средства тут неприменимы (за некоторым исключением).

Можно посоветовать следующее:

  • само собой разумеющееся, отладочный вывод
  • assert с немедленным выходом в «отладчик» (см. следующий пункт)
  • некоторое подобие консольного отладчика
  • проверить не позволяет ли эмулятор подключать отладчик, таблицы символов или ещё что-нибудь
Без встроенного в ядро отладчика поиск ошибок имеет вполне реальный шанс превратится в кошмар. Так что от его написания на некотором этапе разработки просто никуда не деться. А раз это неизбежно, то лучше начать его писать заранее и таким образом значительно облегчить себе разработку и сэкономить довольно много времени. Важно суметь реализовать отладчик независимым от ядра образом, чтобы отладка минимальным образом влияла на нормальную работу системы. Вот несколько типов команд, которые могут быть полезны:
  • часть стандартных отладочных операций: точки останова, стек вызовов, вывод значений, печать дампа, ...
  • команды вывода различной полезной информации, вроде очереди исполнения планировщика или различной статистики (она не так бесполезно как может показаться сначала)
  • команды проверки непротиворечивости состояния различных структур: списков свободной/занятой памяти, heap или очереди сообщений
Развитие
Дальше необходимо написать и отладить основные элементы ОС, которые в данный момент должны обеспечить её стабильную работу, а в будущем - лёгкую расширяемость и гибкость. Кроме менеджеров памяти/процессов/(чего-нибудь ещё) очень важным является интерфейс драйверов и файловых систем. К их проектированию следует подходить с особой тщательностью, учитывая всё разнообразие типов устройств/ФС. Со временем их конечно можно будет поменять, но это очень болезненный и подверженный ошибкам процесс (а отладка ядра - занятие не из лёгких), поэтому просто запомните - минимум десять раз подумайте над этими интерфейсами прежде чем возьмётесь за их реализацию.
Подобие SDK
По мере развития проекта в нём должны добавляться новые драйвера и программы. Скорее всего уже на втором драйвере (возможно определённого типа)/программе будут заметны некоторые общие черты (структура каталогов, файлы управления сборкой, спецификация зависимостей между модулями, повторяющийся код в main или в обработчиках системных запросов (например если драйвера сами проверяют их совместимость с устройством)). Если так и есть, то это признак необходимости разработки шаблонов для различного типа программ под вашу ОС.

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

Дальнейшие действия
Если кратко, то: читать про операционные системы (и в первую очередь именно про их устройство), развивать свою систему (темпы на самом деле не важны, главное - не прекращать совсем и возвращаться к проекту время от времени с новыми силами и идеями) и естественно исправлять в ней ошибки (для нахождения которых надо иногда запускать систему и «играться» с ней). Со временем процесс разработки будет становиться всё легче и легче, ошибки будут встречаться реже, а вы будете зачислены в список «безнадёжно упёртых», тех немногих, которые несмотря на некоторую абсурдность идеи разработки собственной ОС, всё же сделали это.

Рано или поздно каждый пользователь Линукса задумывается над созданием собственного дистрибутива. Некоторые аргументируют это тем, что можно «все настроить под себя». Другие сетуют на то, что среди уже представленных дистрибутивов в Ветке нет идеального. А у них, якобы, есть суперконцептуальные идеи для собственной системы. Зачем я всю эту психологию затеял? Для того, чтобы сразу перекрыть кислород играющимся с Линуксом новичкам, которым делать нечего. Если уж задумались над созданием ОС, думайте до конца. Итак,

Я хочу создать ОС на базе Linux.
Сразу предупреждаю: был бы XVIII век, всех тех, кто для основы своей будущей системы выбирает другой развитый дистрибутив (и, не дай Бог, популярный...) ждала бы виселица. Пост именно про создание системы с нуля, а значит, всякие Slax и Linux Mint мы трогать не будем.

Шаг 1. Выбор носителя
Вариантов немного: либо ваша ОС запускается с LiveCD, либо с жесткого диска, либо с флеш-устройства. Сразу оговорюсь: не скажу в посте ни слова про жесткий диск, потому что гораздо удобнее создавать гибкий дистрибутив из серии «все свое ношу с собой», либо залоченный дистрибутив на оптическом диске. Если вы научитесь создавать LiveCD или LiveUSB систему, с установкой на жесткий диск проблем не будет.

На всякий случай, приготовьте чистую флешку, CD-диск, и установите, наконец, Virtualbox.

Шаг 2. Компиляция ядра
По поводу выхода третьего ядра Linux, этот шаг воодушевляет на дальнейшие разработки… Итак, нам нужны исходники ядра. Каждый пользователь знает, что их можно достать на сайте kernel.org. Ни в коем случае, слышите?, никогда не прикручивайте к своей системе постороннее ядро, скомпилированное не вами!

Поскольку лень моя зашкаливала, я создал папку /linuxkernel и распаковал туда архив с исходниками. Залогинившись под рутом, я сделал следующее:

cd /linuxkernel
make menuconfig

В принципе, ядро можно конфигурировать тремя способами: make config (диалоговая конфигурация), make menuconfig (псевдографическая конфигурация через ncurses), а также make xconfig (графическая конфигурация). Суть в том, что make config испортит вам настроение надолго, т.к. он задаст все возможные вопросы по всем аспектам всех тем. Проблема с make xconfig встречается не у всех, но вот у меня встречалась и встречается. Если приспичило сделать через X, разбирайтесь сами. Оптимальный вариант - make menuconfig. Эта штука откроет вам псевдографический интерфейс, через который вы сможете настроить ядро на свой лад. Штука требует библиотеки ncurses, которая легко устанавливается.

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

Однако, направить вас все же придется. Перейдите по адресу File Systems ---> и поставьте необходимые звездочки. Буква M означает, что поддержка того или иного драйвера осуществляется с помощью подключения к ядру внешнего модуля (ненавижу их!). Нам понадобится также поддержка isofs, для чтения дисков. File Systems ---> CD-ROM/DVD Filesystems ---> ISO 9660 CDROM file system support. Можно еще поддержать древнедосовские системы.

Чмошные разработчики Mandriva забыли разрешить File systems ---> DOS/FAT/NT Filesystems ---> NTFS write support, и на одном из их дистрибутивов я мучился с доступом к древневиндовскому разделу.

Посмотрите Processor type and features ---> Processor family, мне порекомендовали выбрать Pentium-MMX.

Еще поройтесь в Device Drivers, полезно. Можете шутки ради понавыбирать там все и скомпилировать ядро весом > 50 Мб.

Далее. Ядро после загрузки себя должно загружать, собственно, систему. Либо из скомпилированных в себе файлов (используются во встраиваемых системах), либо из CPIO архива, сжатого чем-нибудь, либо из Initrd. Здесь вам не DOS, здесь не получится сразу сослаться на какой-нибудь init"овый файл в корневом каталоге диска или флешки. На самом деле получится, не слушайте дядю Анникса! Неправильно это, хоть в Интернете по этому поводу уже нехилая полемика ведется. В своей системе мы будем использовать initrd, т.к. это удобно, и не вызовет нецензурных выражений от сторонних разработчиков, в отличие от CPIO архива.

Ах, да, скомпилируйте ядро командой

Если у вас x86, найдете его по адресу /linuxkernel/arch/x86/boot/bzImage.

Для суровых челябинских программистов можно использовать Кросс-компайлинг…

Создание Ramdisk.

Теперь нам нужен initrd с установленной там простейшей оболочкой. Мы будем использовать busybox, потому что эта няша может все. Способ мы украдем у Роберто де Лео, создателя Movix (я бы даже уважать его начал, если бы не запредельная любовь к Perl):

dd if=/dev/zero of=/dev/ram0 bs=1k count=5000 - Создаем Ramdisk в оперативной памяти нашего компьютера.
mke2fs -m0 /dev/ram0 5000 - Форматируем Ramdisk в системе Ext2
mkdir /distro - Создаем папку
mount /dev/ram0 /distro - Монтируем в папку /distro

Все, теперь у нас есть Ramdisk, емкостью в 5 Мб. Можно и больше, только не нужно. В отличие от Томаса Матеджисека, я не собираюсь пичкать initrd модулями в Squashfs, сжатыми LZMA. Все, что необходимо, будет скомпилировано вместе с ядром. Да, это не очень логично и правильно, но мороки в сто раз меньше. А специально для тех, кто осуждает такой подход, можно разрешить опцию модульности в ядре: Enable loadable module support.

В нашем Ramdisk"е, смонтированном в /distro, есть такая папка, lost+found. Это потому, что мы отформатировали его в ext2. Ни в коем случае нельзя ее удалять, хоть она здесь вряд ли поможет, образ-то фиксированный. Нам бы busybox сначала поставить…

Установка Busybox
Вот почему у таких классных проектов такие отстойные сайты? Хотя… это уже не суть важно, если исходники скачаны и успешно распакованы в папку /busybox.

Сконфигурировать busybox можно так же:

cd /busybox
make menuconfig

Если вы еще не поняли, что это, объясню. Busybox заменяет тонны UNIX приложений, хранящихся в папках /bin, /sbin, /usr/bin, /usr/sbin. Вместо этого, создается только одно приложение: /bin/busybox, а на него создается куча ссылок в указанных выше папках. Установим busybox следующей командой:

make CONFIG_PREFIX=/distro install

Еще Busybox создаст файлы /sbin/init и зачем-то /linuxrc, чтобы ваша система корректно запустилась. Но не все необходимые папки были созданы. Так что завершаем все руками и создаем:

/distro/etc
/distro/lib
/distro/dev
/distro/mnt
distro/proc
/distro/root
/distro/tmp
/distro/root

Если что забыл - вспомните, т.к. директории эти забыть сложно.

Все бы хорошо, вот только busybox для работы требует библиотеки, которые нужно скопировать в наш дистрибутив. Очень легко узнать, какие:

ldd /distro/bin/busybox

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

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

objcopy --strip-debug откуда куда

Делаем из Линукса Линукс

Надо создать несколько системных текстовых файлов:

Нам нужен /etc/inittab. Удивлю вас: в начале жизни система даже не знает, что такое Root. У нас даже пользователь безымянный, но вот файл общесистемных низкоуровневых фич (ОНФ) должен присутствовать. Пилотное содержание файла следующее:

# Самый первый запускаемый файл, /sbin/init потом.
::sysinit:/etc/rc.d/rc.S

# Запустить оболочку в консоли.
::respawn:-/bin/sh

# Команды, выполняемые перед выключением и перезагрузкой.
::shutdown:/sbin/swapoff -a >/dev/null 2>&1
::shutdown:/bin/umount -a -r >/dev/null 2>&1

Следующий файл - /etc/fstab. Это таблица, в которой описано, что и куда монтировать при загрузке. Вещь бесполезная! Нам нужно обязательно смонтировать proc, иначе вообще ничего работать не будет, так что в файле пишем:

none /proc proc defaults 0 0

Для mount нужен также файл /etc/mtab. Создайте его и оставьте пустым.

Но mount сделает все необходимое только тогда, когда мы явно его об этом попросим. А просить мы будем в том самом первозагрузочном файле /etc/rc.d/rc.S (rc.d - папка). Вежливо попросим:

/bin/mount -av -t nonfs

Еще нам необходим файл профиля (b)(a)sh, тут вообще раздолье для фантазии. Создаем файл /etc/profile и заполняем следующим:

PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:"
LESS=-MM
TERM=linux
HOME=/root
PS1="> "
PS2="> "
ignoreeof=10
export PATH DISPLAY LESS TERM PS1 PS2 HOME ignoreeof

Понадобится также файл /etc/shell, в котором указано, что есть оболочка:

/bin/sh
/bin/ash
/bin/bash

Вот собственно и все. Можно записывать наш Ramdisk в файл.

mkdir /os - папка для "готового".
umount /dev/ram0 - размонтируем кусочек оперативной памяти.
dd if=/dev/ram0 of=/os/initrd bs=1k count=5000 - создаем файл.
gzip /os/initrd - сжимаем файл initrd

Создание загрузочной флешки

«Финишная прямая» нашей маленькой разработки. Берем флешку, вставляем, форматируем в vfat (можно и в ext, но не забывайте, что еще не все пользователи Windows застрелились).

На флешке создаем папку boot, в ней папки initrd и kernel.

Из папки /os копируем сжатый Ramdisk в папку boot/initrd на флешке, называем «main.gz». Из папки с исходниками ядра копируем bzImage в папку boot/kernel на флешке, называем «main.lk». Достаем файлы загрузчика Syslinux (в Интернете, либо из другого дистрибутива: тут не принципиально), а именно syslinux.bin, syslinux.boot, syslinux.cfg. Копируем их в корневой каталог нашей флешки. В файле syslinux.cfg пишем что-то подобное:

default mm
prompt 1
timeout 100
label mm
kernel /boot/kernel/main.lk

label mc
kernel /boot/kernel/main.lk

label cm
kernel /boot/kernel/custom.lk
append initrd=/boot/initrd/main.gz load_ramdisk=1 ramdisk_size=5000 rw root=/dev/ram0
label cc
kernel /boot/kernel/custom.lk
append initrd=/boot/initrd/custom.gz load_ramdisk=1 ramdisk_size=5000 rw root=/dev/ram0
label hd
localboot 0x80

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

Узнаем, каким девайсом в системе является наша флешка (можно запустить mount без параметров и посмотреть). Это либо /dev/sdb1, либо /dev/sdc1, либо /dev/sdd1. Стоит отмонтировать флешку перед началом установки.

Устанавливаем syslinux (если пакета в системе нет, apt-get install syslinux):

syslinux -d путь_к_устройству

В корневом каталоге флешки должен появиться файл ldlinux.sys. Если он есть, значит syslinux.bin, syslinux.boot больше не нужны.

Как настроить BIOS на загрузку из флешки, я вам рассказывать не буду - это легко. Скажу только, что очень удобно создать папку /boot/initrd/init, в которую можно будет смонтировать /boot/initrd/main, для последующей работы с ним. Только не забудьте разжимать и сжимать его gzip"ом.

Ну вот и все.

Как-бы я только что рассказал вам, как создать с нуля систему на Linux. Легко, не правда ли? Далее вы можете редактировать скрипт /sbin/init, ведь у вас еще много работы! Вы должны будете написать скрипт для монтирования флешки, который делает chroot в корневой каталог. В противном случае, вы вынуждены будете работать с ReadOnly разделом, величиной в 5 Мб. Но это уже совсем другая история.