Как выйти на путь разработки ОС

[maisvendoo]

В свое время баловался этим, могу предложить свой цикл статей phantomexos.blogspot.com

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

[maisvendoo]

И да, я бы не рекомендовал крайне Джеймса Маллоя — его код содержит намеренные ошибки, а реализация многозадачности вообще сделана через одно место. В свое время намучился с этим туториалом. Лучше постить свои потуги на osdev.ru, там много толковых ребят, которые способны подсказать полезное.

Вот например так я пришел к реализации многозадачности

[vodozhaba]

Ой. Как раз хотел сделать об этом оговорку, но по пути на Хабр на месте фразы «не лишён изъянов» потерялась ссылка на список подобных ошибок. Исправил. Спасибо!

[Evgen52]

Большое спасибо за интересную статью! Было бы ещё очень здорово в таком же духе, но про x86_64.

[jcmvbkbc]

Вместо того чтобы руками собирать тулчейн можно взять github.com/crosstool-ng/crosstool-ng. Только непонятно, зачем собирать кросс-компилятор под x86 без libc, если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.

[maisvendoo]

если всю ту же функциональность можно получить от хостового компилятора с опцией -ffreestanding.

У меня аналогичный вопрос. Всё нормально собирается хостовым компилятором с соответствующими опциями.

И ещё один вопрос — зачем NASM? Если есть as, вызываемый gcc автоматом, когда тот натыкается на ассемблерный исходник? Ну да, придется попотеть освоив AT&T-синтаксис, ну так это, во-первых несложно, а во вторых — синтаксис ассемблерных вставок и так AT&T. Зачем нужен плесневелый nasm, ради только intel-нотации?

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

[vodozhaba]

В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде -nostdinc, -nostdlib, -m32, которые легко забыть.

По поводу NASM — это просто один из инструментов, применение которого не вызывает особых проблем. Можно было использовать GAS, FASM или TASM. А можно было NASM. Что использовать Вам — дело Ваше.

Про -enable-kvm упомяну.

[a1ien_n3t]

В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру, к тому же появляются лишние флаги вроде -nostdinc, -nostdlib, -m32, которые легко забыть.

Мне кажется, что когда настроить флаги стандартного компилятора проще и рациональнее чем собирать компилятор самому.

[jcmvbkbc]

В хостовом компиляторе есть хостовая libgcc, которая может попытаться обратиться к не менее хостовому ядру

Ну вообще-то нет, не может. Максимум — к функциям из libc, типа abort. Плюс в коде раскрутки стека при исключении есть проверка, специфичная для ОС, но исключения — это вообще отдельная тема, голого компилятора который вы построили для них тоже не хватит.

[vodozhaba]

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

[jcmvbkbc]

тем не менее, для этого нужна хостовая libc

Вовсе нет, никто не запрещает вам определить abort, memcpy, memmove, memset и memcmp в своём коде, по мере необходимости.

[maisvendoo]

Всё решается двумя ключами

-nostdlib — не используем стандартных библиотек
-nostdinc — не используем стандартных заголовков

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

Ваш пример пустого ядра я собирал таким makefile

#------------------------------------------------------
#
# Правила сборки кода ядра
#
#------------------------------------------------------

# Исходные объектные модули
SOURCES=init.o main.o
# Флаги компилятора языка C
CFLAGS=-nostdlib -nostdinc -fno-builtin -fno-stack-protector -m32 -g
# Флаги компоновщика
LDFLAGS=-T link.ld -m elf_i386
# Флаги ассемблера
ASFLAGS=--32
# Правило сборки
all: $(SOURCES) link
# Правило очистки
clean:
-rm *.o kernel
# Правило компоновки
link:
ld $(LDFLAGS) -o kernel $(SOURCES)


и все работало

[vodozhaba]

С -nostdinc не будет весьма полезных заголовков, которые не требуют libc, таких как stddef.h и stdarg.h. Что легче, переписать stdarg.h или собрать компилятор?

[maisvendoo]

Переписать ашник. И вот почему: нельзя просто так взять и пересобрать компилятор. Он ещё должен тесты пройти, почитайте книгу LFS или вот этот материал и станет понятно, что гарантированно работоспособный компилятор и комплект binutils собирается не с наскока, а вдумчиво и долго с обязательным прохождением тестов. На моей машине сборка gcc с тестами заняла 2,5 часа, например + примерно столько же времени на чтение и подготовку

[jcmvbkbc]

Переписать ашник.

Не, вот это точно неправильно. Скопировать стандартный в отдельный сисрут — может быть. Переписать самому — точно нет.

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

Порекламирую crosstool-NG ещё раз. Бэкпортированные патчи из мэйнлайнов компонентов тулчейна и коллективное тестирование идут в комплекте.

[a1ien_n3t]

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

[jcmvbkbc]

Этот makefile будет неустойчиво работать с make -j, потому что link не зависит от $(SOURCES) и перечислен наравне с ними в пререквизитах для all. Правильнее было бы так:

all: kernel
kernel: $(SOURCES)

[neit_kas]

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

[VioletGiraffe]

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

[CodeRush]

Там почти не о чем писать, к сожалению, потому что любое EFI-приложение может выступать в качестве загрузчика, а написание простейшего EFI-приложения на Хабре уже не раз освещалось, и в тех примерах достаточно заменить в inf-файле DXE_DRIVER на UEFI_APPLICATION, и у вас получится нужный вам загрузчик.

[Hixon10]

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

[DungeonLords]

vodozhaba как Вы относитесь к миссии проекта Embox?

[aabzel]

Сборка ядра x86 похоже на программирование микроконтроллеров. Только в MCU есть ROM прямо на чипе.