Разработчик-энтузиаст, изучая исходники Linux, заметил, что старый ноутбук Fujitsu Lifebook S2110 2005 года неправильно обрабатывает нажатие специальных клавиш «Application» и «Player». Он выяснил, что в режиме «Player» клавиши вообще не генерируют события, а в режиме «Application» они работают, но не так, как ожидается. Вместо этого в журнале ядра появляются сообщения об ошибках ACPI. Он подготовил и отправил на рассмотрение патч, который корректно обрабатывает эти клавиши в обоих режимах, и теперь ждет его включения в основную ветвь Linux.

• Участники обсуждали, как начать вклад в ядро Linux: находить задачи по метке «good first issue», писать патч, проходить ревью и попадать в историю коммитов.
• Подчеркивалось, что даже микро-фикс требует тщательной проверки, но именно такие шаги и делают open-source сообщество устойчивым.
• Несколько человек поделились историями о своих первых коммитах в ядро, включая односимвольное исправление макроса, которое потребовало двух недель перепроверок.
• Участники обменялись советами о том, как начать, если ты не знаешь с чего начать: начни с документации, тестов или мелких улучшений.
• Замечено, что даже если патч кажется мелким, он может быть критически важным для конкретного оборудования, и что такие патчи могут быть применены к старому железу.
• Поднята тема о том, что вклад в ядро Linux может быть полезен при приеме на работу, и что такой опыт ценится.

Разработка ядра операционной системы с нуля

Недавно я реализовал минимальное ядро ОС с разделением времени для RISC-V. В этой статье расскажу о деталях работы прототипа. Материал предназначен для всех, кто интересуется низкоуровневым ПО, драйверами, системными вызовами, и особенно полезен студентам, изучающим системное ПО и архитектуру компьютеров.

Это переработанная версия учебного проекта по операционным системам, но с фокусом на современные инструменты и архитектуру RISC-V. RISC-V — перспективная технология, которая проще для понимания по сравнению с другими архитектурами, оставаясь популярным выбором для новых систем.

Вместо традиционного C я использовал Zig, что упрощает воспроизведение эксперимента благодаря простой настройке и отсутствию необходимости установки дополнительных инструментов для кросс-компиляции под RISC-V.

Репозиторий и рекомендации

Исходный код доступен на GitHub. Перед изучением рекомендуется ознакомиться с основами программирования на RISC-V без ОС, процессом загрузки через SBI и обработкой прерываний.

Архитектура

Мы разрабатываем унике́рнел (unikernel), где приложение и ядро объединены в один исполняемый файл. Это исключает необходимость отдельной загрузки пользовательского кода во время выполнения.

В основе стека лежит слой SBI (OpenSBI), который управляет выводом на консоль и таймером. RISC-V использует уровни привилегий: M-режим (машинный), S-режим (супервизора) и U-режим (пользовательский). Наше ядро работает в S-режиме.

Цели ядра

1. Статическое определение потоков (без динамического создания).
2. Потоки выполняются в пользовательском режиме и могут делать системные вызовы к ядру.
3. Время распределяется между потоками с помощью таймера, который прерывает выполнение каждые несколько миллисекунд.
4. Разработка ведётся для одноядерной системы.

Виртуализация и потоки

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

• Автор переписал классическое упражнение по созданию минимального ядра ОС с разделением времени для управления пользовательскими потоками.
• Целью был эксперимент на специфической платформе RISC-V в сочетании с OpenSBI.
• Для реализации был использован язык программирования Zig вместо традиционного C.
• Автор отмечает, что подход можно легко повторить на C или Rust.
• Участник обсуждения предположил, что эта тема уже публиковалась неделей ранее.
• Другой участник уточнил, что оригинальный пост был два дня назад на Hacker News.
• Было отмечено, что текущий пост, хотя и от первоначального автора, изначально не получил отклика и был повторно запущен через «пул второго шанса» с измененными временными метками.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

Разные устройства регистрируют свои реализации ops, а вызывающий код работает с единым интерфейсом. Таблицу можно менять на лету без изменения клиентов.

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

Позволяет из терминала запускать/останавливать потоки без хардкода.

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.