Comments 84
В этой статье мы пройдём путь создания простого, но функционального ядра операционной системы на языке C.
тут многа букв, но среди них нет "PC" или "Intel", или хотя бы упоминания архитектуры , зато есть номера прерываний, что явно указывает на использование Ибием Писи архитектуры.
Аллокатора
Про принципр работы рассказано в первой статье, но здесь мы затронем работу аллокатора немного глубже.
Это на каком языке написано?
Как тут принято говорить - "немного подушним".
Во-первых, из текста статьи не ясно работает Ваша ОС в Real Mode или Protected Mode ?
Хотя вот, нашел.
Создание ядра — мы настроили загрузчик, инициализировали
GDTиIDT, подготовили окружение для работы в защищённом режиме.
Во-вторых, есть неточность:
Минусы FAT16
Нет поддержки папок и поддиректорий — все файлы находятся в корне.
File Allocation Table с версии 12 (FAT12, FAT16 и FAT32) поддерживают иерархическую структуру подкаталогов. Список файлов подкаталога хранится в файле со специальным атрибутом "directory".
На мой взгляд основными недостатками FAT12 и FAT16 являютя:
Отсутствие поддержки прав доступа и принадлежности к пользователю. В Novel Netware, OS/2 LAN Manager, Linux VFAT и прочих сетевых ОС добавили свои несовместимые расширения (extended attributes) для решения этой проблемы.
Ограничение на формат имени файла: 6.3 или 8.3. Проблема решалась костылем - файлы с закодированными названиями и отдельный файл с таблицей перевода закодированного названия в нормальное.
Теперь вопрос. Как Вы реализовали преобразование сканкода нажатой клавиши в ASCII код ? Задача эта весьма нетривиальная. Я столкнулся с ней когда писал программу Монитор для своей синтезируемой СнК KarnixSoC, мне требовалось сделать свой видео-терминал чтобы пользователь мог управлять устройством с помощью клавиатуры и VGA. В итоге, самое минималистичное решение обнаружилось в ядре ОС Linux. Код видео-терминала там организован в виде небольшой виартуальной машины с семью таблицами (программами). Мне удалось вырезать этот код и адаптировать под свои нужды. Интересно как это сделано у Вас.
Добрый день.
Действительно, в FAT16 есть директории. Похоже, в источнике, откуда я брал первоначальную информацию, были неточности — спасибо за замечание, исправлю этот пункт.
Что касается сканкодов: я создал массив символов, в котором каждому коду соответствует свой символ, и просто перебирал соответствия «код → символ». Минус такого подхода — сложность добавления новых языков. Тем не менее для защищённого режима этого вполне достаточно, так как базовый VGA-ASCII выводит только латинский алфавит (русского там нет); остальные языки я не проверял.
P.S. В статье обновлён пункт «Создание базовой файловой системы».
В ядре теперь реализованы директории и папки.
Кроме алфавита есть ещё раскладка, состояние shift и caps lock и ещё немножко всякое разное.
Добрый день.
Клавиши вроде Caps Lock, Shift и других тоже имеют свои уникальные коды при нажатии, и их можно легко обработать.
Вместо поиска значения в массиве мы можем обрабатывать их напрямую, например, для изменения размера клавиш и других действий.
Реализация в моём ядре:
if (key == KEY_LSHIFT || key == KEY_RSHIFT)
{
shift_down = !released;
pic_send_eoi(1);
return;
}
if (key == KEY_CAPSLOCK && !released)
{
// при нажатии (make-код) — переключаем
caps_lock = !caps_lock;
pic_send_eoi(1);
return;
}char get_ascii_char(uint8_t scancode)
{
if (is_alpha(scancode))
{
bool upper = shift_down ^ caps_lock;
char base = scancode_to_ascii[(uint8_t)scancode]; // 'a'–'z'
return upper ? my_toupper(base) : base;
}
if (shift_down)
{
return scancode_to_ascii_shifted[(uint8_t)scancode];
}
else
{
return scancode_to_ascii[(uint8_t)scancode];
}
}Будем считать это корректным, но ad-hoc решением.
А как быть с управляющими символами типа Ctrl-C/Ctrl-X/Ctrl-Z ? С кнопками управления курсором ? Чтобы сделать полноценную строку ввода команд придется попотеть.
Добрый день.
Терминал пока версии 0.1. Весь функционал будет постепенно добавляться и дополняться. На данный момент это предрелизная версия.
поидее надо писать терминал(VT220 минимум с обработкой ANSI esqape sequentional convenience) с зависимостями(планировщик,процессы,сигналы), терминал даст доступ к логин сессии и требует getty и tty сессий
У меня пока что в планах сделать из Монитора что-то типа CP/M (однозадачную ОС) с удобной командной строкой: перемещение курсора, редактирование, запоминание истории, и т.д. А также скриптовый язык (я-ля .BAT) чтобы можно было автоматизировать запуск различных программ и осуществлять пакетную обработку. В целом этого достаточно для широкого круга задач пром и домашней автоматизации.
это интересно, успехов вам, я пока кайфую в vt граффическом режиме в фрибсд покачто, но многому научился тут, в том числе тому как написать сессионный терминал(на самом деле терминальный емулятор) пускай и на стандартной библиотеке
вообще как в реальности по правильному запускать после уефи я не знаю, знаю только что у уефи есть стандарт и спецификация, и уефи вроде запускает начально ядро
побольше теории с обзором я видел только в ютубе ищите в ютубе, название канала уже забыл
из практики могу сказать, что помимо обвязок ОС софта на бекграунде может помочь то как работать со строковым буффером(его организация и многие функции по работе с ним), всё остальное по АНСИ это просто парсинг и совмещение с функционалом самого буффера
тоесть можно начать с чего-то попроще например текстовый редактор на С, или терминальный емулятор(как вы понимаете у обоих суть это строковый буффер)
тоесть на С контейнер строка и сущность буффера чтобы его рисовать(тоесть контейнер с контейнером)
тоесть получается вы пишите про CP/M получается его проще емулировать как layer например, или выбор емуляции из доступных, и тогда вопрос стоит так, как запускать видео драйвер например VESA, и какой язык например С, а это уже поддержка fork+exec (мы же не будем писать с нуля эти концепции) тоесть это библиотека libc, и сам бутлоадер или как в Юникс или Граб тут тоже моменты выбора, соотв ядро либо как в линуксе либо как в Юниксе
еще присмотритесь может поможет к OpenIndiana тоже классная система
VGA-ASCII поидее можно расширить ввести кодпейджи текстурные вначале загрузки тогда выбирать язык резать текстурки(ну например базовые какие-нибудь 8х16 и так далее ) оставляя 1-2 базовых, и поидее bitmap текстурки выводить, поидее это мини переносная ситуация с языком и битмап шрифтом, например я делал шрифт тоже битмап в рейкасте, там текстура на аски 256х256 режу потекстурно памяти мало занимает
Торвальдс, перелогинтесь!
Создание своего ядра на C
Читаю и сразу в голове: "это про ядерный электорат?". Вот дожили! Ужас.
Спасибо за статью. Интересно было бы подобное на Zig под RISC-V почитать.
sti ; разрешить прерывания
popfd ; восстановить EFLAGS
iret ; возврат из прерыванияЭпилог обработчика прерывания немного избыточен и даже некорректен: во-первых, при входе в прерывание флаги уже на стеке, и ещё раз пушить их нет смысла. Во-вторых, команда iret обеспечивает атомарную операцию, в которой восстанавливаются флаги и осуществляется длинный переход на сохранённый адрес возврата.
У Вас же получается разрешение прерывания до выхода из обработчика, что приводит к тому, что другой обработчик может вытеснить выполнение сразу после инструкции sti. Далее, popf всё равно восстановит флаг прерываний, ранее сохранённый, поэтому операция sti перед popf тут избыточна.
/* Берёт символ из буфера без блокировки. Возвращает -1 если пусто. */
char kbd_getchar(void)Строго говоря, char не обязательно знаковый и -1 может не быть в диапазоне допустимых значений.
Почитал подводку — интересно!
Раскрыл статью — и тут откуда ни возьмись™ появился x86 :(
Извините, все не осилил, многабукв. Эта ОС может быть загружена только с MBR диска и только если ПК поддерживает BIOS simulation? Или можно запустить на чистом UEFI?
Мы копируем программу с диска (RAMDISK/файловой системы) в область
.userв памяти ядра, потому что CPU не может напрямую исполнять код с файловой системы.
мне кажется, что те, кто лезут в тему создания ОС должны уже как-то понимать такого рода штуки
gpt5 :
ChatGPT
gpt-5
Коротко про что статья
Пошаговая сборка учебного 32‑битного ядра под x86 с загрузкой через GRUB (Multiboot): стартовый ASM-стаб, kmain.
Вывод в VGA-текстовый режим, управление аппаратным курсором.
Клавиатура: обработчик IRQ1, кольцевой буфер ввода, раскладки Shift/CapsLock.
Таймер PIT (IRQ0): учёт времени и точка входа планировщика.
Системные вызовы через int 0x80.
Свой аллокатор памяти: куча ядра (.heap) + отдельная «user»-область (.user).
Вытесняемая многозадачность (IRQ0, round-robin), создание/завершение задач.
Базовая «FAT16 на RAM-диске» и загрузка/запуск пользовательских ELF-приложений в .user.
Что важно: это прототип в одном адресном пространстве без настоящего user-mode; «пользовательские» задачи фактически исполняются в режиме ядра.
Замеченные ошибки, неточности и потенциальные баги
Двойной EOI в обработчике клавиатуры. В C-обработчике вызывается pic_send_eoi(1), и ещё раз EOI отправляется в ASM (out 0x20, 0x20). Должен быть ровно один EOI.
Возврат из прерываний. В комментариях вы уже отреагировали: перед iret/iretd не нужны sti/popf; важно, чтобы это исправление было везде.
kbd_getchar возвращает char и использует -1 как «пусто». На платформах с unsigned char это сломается. Нужен тип int и чёткая семантика возврата.
Syscall GET_TIME возвращает указатель на строку str, но в приведённом фрагменте переменная str не определена. Кроме того, возвращать внутренний буфер ядра небезопасно. Лучше вернуть число (секунды/мс) или писать в буфер вызывающего, с валидацией указателя.
Архитектура не названа в шапке. В тексте используются x86-специфичные детали (PIT, PIC, порты 0x60/0x64, int 0x80). Это нужно явно обозначить.
Обработка клавиатуры упрощена: нет поддержки расширенных сканкодов (E0/E1), клавиш управления курсором, комбинаций Ctrl/Alt, автоповтора, break-кодов для не-модификаторов.
Частота PIT: init_timer(1000) подразумевает divisor=1193180/1000≈1193. Точность «секунд» и длительных интервалов будет дрейфовать; нет калибровки.
RAM‑диск как статический массив 64 MiB в .bss, плюс .heap 32 MiB и .user 128 MiB — итого ~224 MiB статически зарезервировано. На машинах с 128–256 MiB ОЗУ ядро может просто не запуститься.
FAT16 описана упрощённо и реализована как «похожа на FAT» над массивом. Для FAT16 требуются BPB, таблицы FAT, корневой каталог в определённых секторах и т. п.; текущая реализация — учебная имитация.
Syscall/копирование данных. Нет валидации пользовательских указателей (copy_from_user/copy_to_user). В текущем виде любой «пользовательский» код может передать адрес в память ядра.
«Пользовательские» задачи работают в CPL=0. Нет привилегий (ring3), TSS, стека ядра, DPL=3 на int 0x80 — это не настоящая изоляция процессов.
Планировщик не учитывает FPU/SSE контекст. При использовании плавающей точки между задачами возникнут порчи состояния.
Прерывания и критические секции. Есть локальные cli/sti, но нет системного счётчика preempt_disable/preempt_count; возможны нежелательные вытеснения в чувствительных местах.
Инициализация Multiboot-заголовка. В линкер-скрипте есть секция .multiboot, но в boot.asm заголовок не помещён в неё. Лучше гарантированно класть заголовок в первые 8 КБ файла через отдельную секцию и KEEP.
Мелочи по выводу: print_string не обрабатывает перенос строки/прокрутку; курсор лучше обновлять буферно, а не на каждый символ (микролаги).
Предлагаемые улучшения (по приоритету)
Исправления, не меняющие архитектуру
Убрать двойной EOI. Оставить EOI либо в ASM-обвязке, либо в C-обработчике, но не в обоих.
kbd_getchar: вернуть int; пусто — -1; явная договорённость с вызывающими.
Syscall GET_TIME: возвращать число (uint64_t мс/тики); для строк — принимать буфер + размер и заполнять его.
Обработка расширенных сканкодов: поддержка E0/E1, стрелки, Home/End, PgUp/PgDn, Ctrl/Alt, Ctrl+C/Z и т. п. Хранить в буфере именно сканкоды и преобразовывать в ASCII в слое терминала — гибче.
Таймер: держать 64‑битный счётчик тиков; добавить калибровку TSC против PIT (или позже перейти на APIC/HPET).
Линк: разместить Multiboot header в отдельной секции .multiboot (KEEP) до .text, чтобы гарантировать видимость GRUB; проверить выравнивания.
Консоль: добавить \n, \r, табуляции, прокрутку кадра; курсор обновлять пачками.
Документация: явно указать «x86 (i386), Protected Mode, Multiboot1/GRUB». Кратко описать опции сборки (-ffreestanding, -fno-builtin, -nostdlib, кросс‑компилятор i686-elf-).
Безопасность ABI и стабильность
Валидация указателей в syscalls: хотя сейчас всё в CPL=0, лучше сразу ввести проверки на диапазон .user. Это подготовит к переходу на ring3.
Единая конвенция ошибок для syscalls: отрицательные errno, типы возврата size_t/ssize_t для I/O, чёткие контракты «неблокирующий/блокирующий».
Клавиатурный ввод: вместо busy-poll kbd_getchar добавить блокирующий read с ожиданием по событию (wait queue) + неблокирующий режим.
Планировщик/вытеснение
Добавить состояния задач SLEEPING/BLOCKED, таймауты сна, очереди ожидания по объектам (клавиатура, таймер).
preempt_disable()/enable() и счётчик в TCB, чтобы исключить вытеснение в критических секциях.
Сохранение FPU/SSE: FXSAVE/FXRSTOR по флагу использования (lazy FPU) или всегда.
Тики/квант: параметризовать timeslice; статистика использования CPU.
Память
Страничный аллокатор (buddy/bitmap) и включение paging (CR0.PG). Это даст:
раздельные виртуальные адресные пространства;
защиту от порчи памяти между задачами;
W^X (RX для .text, RW для .data).
Перенос «user» в отдельное виртуальное пространство и реальный user-mode (ring3): GDT с селекторами DPL=3, TSS для переключения стека ядра, IDT gate int 0x80 с DPL=3, проверка и копирование буферов user<->kernel.
Аллокатор ядра: выравнивание до 16 байт, охранные канарейки, отладочная запись паттернов при free, список свободных блоков по классам размера (slab/segregated fits) для снижения фрагментации.
RAM‑диск: не статический массив. Варианты:
загрузка initrd как Multiboot-модуля (GRUB modules);
выделение под RAM‑диск из физического аллокатора на старте;
позже — реальный блоковый драйвер + кэш страниц.
ELF-загрузчик: корректная обработка PT_LOAD с p_vaddr/p_memsz, инициализация .bss нулями, проверка флагов RX/RW, выравнивания страниц, (при paging) маппинг в адресное пространство задачи. Пока без релокаций — статически слинкованные ELF.
Прерывания и железо
Общая логика EOI: для IRQ ≥ 8 (slave) сначала EOI в slave (0xA0), затем в master (0x20). Унифицировать pic_send_eoi(irq).
Убрать лишние cli в int 0x80-обвязке и полагаться на тип gate (interrupt vs trap), держать минимальную латентность.
Экспертно: перейти от PIC к IOAPIC/Local APIC, добавить источник высокоточного времени (HPET/TSC-deadline), но это уже «следующий этап».
Файловая система
Если цель — учить, честно назвать «упрощённый FAT‑like поверх RAM». Если цель — совместимость, реализовать настоящий FAT16: BPB, FAT таблицы, корневой каталог, LFN при желании, корректные коды EOF/坏 кластеров, кластеризация и выравнивания.
Интерфейс VFS‑образного слоя: абстракция inode/файлов/директорий и драйвер блокового устройства — чтобы можно было заменить RAM‑диск на диск/образ без переписывания остального.
Мини‑патчи по коду
isr33: EOI только в одном месте. Например, оставить в C и убрать из ASM-обвязки.
kbd_getchar:
сменить сигнатуру на int kbd_getchar(void);
вернуть -1 при пустоте, 0…255 для байта данных.
int 0x80 wrapper: убрать лишний cli, сохранить/восстановить ровно те регистры, которые нужны; документировать ABI (eax=num, ebx..).
Итог Статья охватывает внушительный объём: от загрузки ядра до простого многозадачного окружения с выводом, вводом, системными вызовами и «файловой системой». Как учебный проект — отлично. Главные технические долги: отсутствие реального user-mode и виртуальной памяти, недочёты в обработке прерываний (EOI, обвязки), упрощённый ввод с клавиатуры, статический RAM‑диск и нерелизный ABI syscalls. Если целитесь в следующий уровень стабильности и изоляции — начинайте с paging+ring3, вычистите ISR/EOI/ABI и добавьте основы VFS/блоковых устройств. Это даст качественный скачок без радикального усложнения кода.
фс надо подтянуть до zfs-like filesystem это точно, на загрузчике оставить свою фс по конвенции наверно, остальное я не разбираюсь, ну с зфс я по вики смотрел когда-то там интересная структура достаточно ( работа с деревом(например отрезков) на манер деревьев )( если прогружать процессор может быть ускорение )
по ощущениям нужны дескрипторы ( типовые хотябы /in /out /err /null /zero /random )
ну база данных аля user-scope (наверно)
ну и составление синхронизации(открытых буфферов при отключении) при выключении из последних фишек
Как-то у вас куски кода вразнабой.
; boot.asm — точка входа, Multiboot‑заголовок
/* kernel.c */
??? какие-то секции, bss - это ещё один кусок boot.asm?
??? рандомные куски кода на Си
isr.asmоткрываешь репо, а там все аккуратно разложено, но абсолютно непонятно, где искать все эти куски кода кроме как через поиск
Ну и отдельно приколы типа
Ассемблерный код похож на таковой под 32-битные x86 процессоры. Почему именно эта архитектура и не x86_64? Примеры кода найти проще?
start:
cli ; отключаем прерывания
mov esp, stack_top ; настраиваем стек
call kmain ; переходим в C‑ядро
Инструкция cli, насколько я знаю, запрещает маскируемые прерывания. И не совсем понимаю зачем тут нужна данная инструкция, вроде mov esp - операция атомарная. Могу предположить, что это связано с тем, что данная строка встречается в 99% MBR загрузчиков и имеет смысл только в том случае, если ОС будет запускаться на первых ревизиях 8086, в которых отсутствовала атомарность при изменении стекового сегментного регистра.
Добрый день.
Команда cli используется для отключения прерываний до создания таблицы IDT (Interrupt Descriptor Table).
Если не отключить прерывания заранее, процессор при их возникновении будет обращаться по неинициализированным адресам, что приведёт либо к крашу ядра, либо к неопределённому поведению.
После того как таблица прерываний создана и установлена, а также настроена необходимая маска прерываний, их можно снова включить с помощью команды sti. После этого прерывания будут обрабатываться корректно.
Это все действительно так, но разве не логичнее отключать эти самые прерывания непосредственно перед загрузкой дескрипторов? Тем более в статье ничего не написано про переход в защищенный режим, а ведь как раз после него прерывания BIOS перестанут работать. Извиняюсь за свою тупость, но я правильно понимаю, что подразумевается, что компьютер стартует при помощи BIOS?
Как говорила моя преподавательница по матану:
«Нет тупых вопросов, есть глупые ответы».
Так что разбираемся.
1) Переход в защищённый режим
Создание ядра — мы настроили загрузчик, инициализировали
GDTиIDT, подготовили окружение для работы в защищённом режиме.
2) Старт при помощи BIOS
Любая система и любой компьютер запускается через BIOS.
Процесс выглядит так:
Нажатие кнопки включения → BIOS подаёт питание на CPU → процессор начинает выполнять инструкции по адресу BIOS → поиск загрузочного устройства (в порядке, указанном в настройках BIOS) → копирование первого сектора (512 байт) в ОЗУ → загрузка загрузчика.
3) Зачем нужна cli перед созданием таблиц прерываний
Почему нельзя отключить прерывания только перед созданием таблицы?
Да, некоторые загрузчики могут автоматически устанавливать флаг CLI по умолчанию. Но это не гарантируется. Если при переходе в Protected Mode прерывания не отключены, ядро может сразу начать получать IRQ-сигналы (например, от клавиатуры, мыши, дисков, таймера).
Процессор попытается обработать их, обратившись к адресам в таблице IDT, которой ещё нет. В итоге он попадёт на «мусор» в памяти, что приведёт к краху ядра или неопределённому поведению.
Поэтому при старте ядра не лишним будет самостоятельно отключить прерывания с помощью cli, чтобы избежать подобных проблем.
Надеюсь, я ответил на ваш вопрос.
Любая система и любой компьютер запускается через BIOS.
Интересно Вы конечно дали, я так понимаю UEFI запускается тоже через BIOS?
Спасибо за подробные объяснения, хоть я их и не просил. Вы меня немного не поняли видимо, я лишь указал, что лучше перенести cli непосредственно перед переходом в защищенный режим и загрузкой дескрипторов. Просто это выглядит как то странно, я вообще изначально подумал, что это сделано, чтобы прерывание не разрушило память в загрузчике, так как неизвестно куда установил стек BIOS.
Надеюсь на статью про написание ATA или если повезет, AHCI драйвера.
Всё же я бы не отнёс статью к сложным. Знать надо многое и быть подготовленным - да, но это не относится к сложности почти.
А так, почитаю, изучу. Хотя мне не совсем эта информация нужна, но зная как всё работает, лишней информация точно не будет и пригодится даже если делать ядро для другой архитектуры.
Здравствуйте, команде ExTeam понравился ваш проект, и мы хотим его дорабатывать под именем EXOS, вы не против? (Мы обязательно укажем автора ядра). Но у нас есть пару вопросов, мы запустили ваше собранное ядро через QEMU, и да, всё работает, но мы не понимаем, какие команды доступны для выполнения из терминала, всё, что мы вводили, не выполняется. И еще, где создавать программы для терминала, в совместимости с какой системой писать программы (Linux, Windows) и в каком формате они должны быть?
Добрый день.
Ваше предложение звучит очень интересно.
Хотелось бы подробнее узнать о вашей команде, так как, честно говоря, я впервые о ней слышу. В частности:
Какие проекты вы реализовывали ранее?
Немного информации о вас.
На данный момент в ядре нет полноценной командной системы, так как ещё не написаны программы (кроме терминала), которые могли бы выполняться.
Инструкции по сборке приложений для ядра описаны в файлеuser/README.md.
Для написания программ не важна используемая система — главное, чтобы их можно было собирать в формате ELF-32 (в дальнейшем, после реализации Long Mode, — ELF-64).Также требуется доработка приложения Terminal, чтобы оно корректно запускало программы через syscall.
Сейчас я работаю над реализацией загрузки в Long Mode.
Полная загрузка и запуск через GRUB теперь работает. Сам Long Mode реализован, но многозадачность пока работает нестабильно — разбираюсь с этим.
Если интересно, код доступен в веткеExperimental kernel.
Вопросы к вам:
Проект планируется остаться open source?
Будет ли возможность вносить изменения и дорабатывать его (например, создавать pull requests), если мне покажется интересна ваша реализация?
Здравствуйте, да, почти никто не знает о ExTeam, так как мы упоминали, что команда "новорожденная" и появилась совсем недавно.
По поводу проектов:
Многочисленные системные утилиты.
Полноценный эмулятор DOS полностью на Python (На данный момент он утерян)
Создание различного тестового вредоносного ПО (Не рекомендуем)
Много чего еще
По поводу нас: Мы появились совсем недавно, основателем является человек по имени Алексей. О нас ещё никто не знает, потому что у нас пока нет официальных ресурсов с информацией о нас. Больше всего проектов у нас основано на Python, но мы не собираемся останавливаться на этом. В программировании на C, ASM у нас мало опыта пока.
Проект будет open source всегда, мы являемся сторонниками ПО с открытым исходным кодом.
Да будет возможность, каждый человек сможет скачать исходный код (Когда это уже будет возможно) и что-нибудь изменить.
Я вас попрошу создать скрипт (Например, на Python), который предоставит возможность собрать ядро из под Windows.
Если вы хотите, мы можем с вами связаться в каком-нибудь мессенджере на ваше усмотрение и обсудить это.
Сразу предупреждаем, команда состоит из одного человека, я пишу от имени тех людей, которых нет :)
Добрый день!
Если вам удастся создать качественную ОС на базе моего ядра — это будет здорово.
В принципе, у меня больше вопросов нет.
Я не против, так как мы делаем два разных продукта: я — ядро, вы — ОС на его основе.
Есть небольшая просьба:
Если в дальнейшем в вашей ОС появятся драйверы (диски, устройства и т.д.), прошу предоставить возможность интегрировать их напрямую в моё ядро.
Сами программы и всё, что будет сделано вокруг ядра, я забирать не планирую, так как моя цель — разработка именно ядра, а не полноценной ОС.
Если вашей ОС потребуется реализовать дополнительные syscall или другой функционал, связанный с ядром, вы можете оставлять предложения в разделе Discussions на GitHub.
Желаю вам успехов в развитии вашей EXOS!
Мы планируем пока вместе с вами развивать ядро. Спасибо!
Здравствуйте, команда ExTeam обновила вашу файловую систему, подробнее вы можете посмотреть во вкладке Discussies на вашей GitGub странице с ядром. Спасибо. - ExTeam.
Хотел бы обратится к вам, я начал создавать свое ядро, и увидел вашу статью, и решил что буду постепенно интегрировать ваши наработки к себе но с изменениями, конечно, пока что я взял у вас только прерывания, клавиатуры и немного изменил вывод текста, но в будущем хочу сделать все совместимы с вашим ядром.
Здравствуйте, вы тоже захотели приняться за разработку ядра? Если это так, то мы вполне можем объединиться и разрабатывать ядро вместе. Наша команда ExTeam (Которая состоит из одного человека (К сожалению)) будет разрабатывать операционную систему на основе этого ядра, и мы уже улучшили файловую систему, но сейчас ждем ответа от Elieren'а. Рекомендуем вам рассмотреть наше предложение. Спасибо.
Боюсь пока, моё ядро слишком маленькое, я не добавил файловую систему(планирую как минимум fat32 и поддержку usb накопителей), не сделал многозадачность и пользовательский программы, я лишь пока использую код ядра Elieren для написания своего, поэтому разработка идёт долго(и тут ещё такие обстоятельства - ШКОЛА, не знаю, сможете ли вы положится на 14 летнего подростка...(это я про себя) )
Добрый день!
Насчёт возраста у меня нет предубеждений.
Если вы способны внести свой вклад в это ядро, мы будем только рады и благодарны.
Я пока разрабатываю свое ядро, но если захотите вы сможете использовать функции моего ядра, я постараюсь сделать его совместимы с вашим(на счёт запуска программ)
https://github.com/DankarLisiyGlobus/globus25_kernel_C/tree/main Вот репозиторий, где вскоре выложу код. (надеюсь меня не засмеют, я на C впервые пишу код, до этого только python и javasciprt)
Можно вопрос?
uint32_t isr_timer_dispatch(uint32_t regs_ptr)
Данная функция в time/time.c для чего?
Я могу вам предоставить файловую систему. Это FAT16, но мы его улучшили.
Спасибо, когда понадобится обращусь, сейчас буду реализовывать системные вызовы и Системное время
(всего 2 дня как начал писать ядро)
Скорее FAT32 с некоторыми особенностями FAT16.
То есть поддерживается:
больше хранимых данных,
увеличенная длина имён файлов,
большее количество файлов и файлов большего размера.
При этом, как и в FAT16, отсутствуют права доступа, принадлежность к пользователю и другие специфические особенности FAT16.
Здравствуйте, как мы увидели, вы решили обновить файловую систему на нашу. Спасибо, мы очень стараемся над вашим ядром. Есть ли ошибки?
Ну ошибки с размером переменных, по большей части.
В вашем коде используется uint16_t, что ограничивает максимальное значение до 65535, тогда как вы указали FAT_ENTRIES = 600000.
Это могло бы привести к проблемам или неопределённому поведению.
По большей части из ошибок, это ошибка типов (uint16_t), хотя по объёму это уже ближе к полноценной FAT32.
Я также внес небольшие оптимизации:
возможность читать и записывать файлы по фрагментам,
более точные проверки.
В результате теперь есть недо-реализованная FAT32, которая позволяет хранить файлы большего размера.
В начале статьи нехватает описания, зачем всё это, под какие платформы, какая архитектура и т.д. В более ранней статье, там тоже не лучше - "что бы показать, что можно"... Имхо так себе обоснование. Нечего показывать, итак понятно, что можно, хоть что-то простенькоt в несколько кбайт на подобии baremetal helloworld. Основной вопрос, зачем и только потом всё остальное.
На счёт архитектуры, да не написал автор, но хоть немного прошаренные люди уже понимают, что на x86, автор все отлично оазьясняет, но в статье конечно недостаточно кода и информации, поэтому все советую после статьи самостоятельно изучить исходный код на Git Hub
Не нужно быть прохаваным, что бы увидеть в начале x86-64. Только там емть и про арм, но с растом под это печаль. А под что вообще в итоге планирует, не написано.
Обьясняет как раз сильно поверхостно. Почему си, а не плюсы? Хотя бы ради почти нормального ноаого энума и иногда ради класмов. Нет, си. И т.д.
Элементарно кучу вещей додумывать нужно, изучать по теме где-то ещё (нет ни ссылок, ни ещё какого упоминания), что бы понять, что он вообще делает. На х86-64 есть не только уэфи, на армах тоже есть нюансы. И т.д.
Такой код изучать смысла мало (разобраться в более нормальных источниках, как сделать и в общем кучу всего изусить, что бы понять, что он тут вообще делает?...). Проще изучить исходники (которых не мало) других загрузиков, где в описании поболее описано, зачем, в каком режиме, под что. И т.д. А не этот проект, с которым ещё нужно угадать, он хочет минимумом еода хэллоувоод сделать или ещё что. Тем более полно документации и статей, где очень хорошо всё обьясняется и про платформу и про загркзку и прочее. У интела только доккментации не мало, а ещё есть блдк (бутлоадер девелопмент кит) и много чего ещё.
добро пожаловать первые часа 4 только теории необходимой для того как оно устроено с минимальным теоретическим обзором
предпологается что поняв азы(как мы понимаем чтобы их понять надо понять о чем реч вообще) на нужный язык тот кто смотрит сам переведёт (язык программирования)
С потомучто минимальная зависимость(без учета посикс и стандартной библиотеки), которой покачто нету аналогов как я понимаю
Без разницы, что там предполагается. В статье есть только то, что в ней есть. Вот пролистал немного - фигня какая-то, ни рыба ни мясо. Не описано даже для чего делается, какая архитектура, под какие платформы,... С дургой стороны в ней есть примерно ничего базового. Нужен загрузкик, ну так готовый можно взять и всё - есть и с уефи и без, есть под х86-64, армы,... Нужна информация про базовые вещи, полно всего, даже всякие толмуды на сотни, а иногда и на тысячи страниц. Сдк и и прочее тоже есть. По ОС тоже прилично всего, есть и опенсорсные ОС, бери, изучай и используй. И тд. И какой смысл в этой статье ни о чём? Нет его. Не, если вам хочется это непойми что ("клепаем минималистичный бареметал хэллоу ворд") и не пойми ради чего, ну читатйе статью, берите себе этот проектик для чего.
Здравствуйте, команда ExTeam обновила ваш терминал, добавив базовую систему команд, но есть проблема, мы оставили в сообщении на ГитХаб подробности.
спасибо за статью про ядро интересно будет почитать действительно, как не хватало примеров, но вроде UEFI загрузчик грузит ядро, ну тоесть оборудование проверяется на поддержку это вроде и есть загрузка ядра, а далее уже что-то другое), у меня мечта написать ОС минимальную с выходом в терминал тоесть до pty )
монолит Unix минимальный топ вообще) структура Юникс интересная, дойдут руки поделаю )
Создание своего ядра на C