Board.KolibriOS.org

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

---
Описание цели:

Загрузка Колибри ОС с физического носителя должна происходить таким образом, чтобы системные файлы Колибри ОС (содержимое "kolibri.img") находились непосредственно на физическом носителе, присутствие образа "kolibri.img" на физическом носителе должно быть опцией, а в случае присутствия на физическом носителе одновременно файла образа "kolibri.img" и системных файлов Колибри ОС, приоритет загрузки должен отдаваться системным файлам на физическом носителе.

Описание процесса:

0. Каталогизированные системные файлы ОС (содержимое "kolibri.img") находятся на физическом носителе, в каталоге Kolibri;
1. Загрузчик проверяет наличие системного каталога "Kolibri" на физическом носителе;
2. Если системный каталог найден, загрузчик считывает все каталогизированные файлы из системного каталога и копирует их на динамический FAT-диск (виртуальный "kolibri.img") /rd/1;
3. Происходит загрузка ОС в штатном режиме.
4. Если системный каталог не найден, загрузчик проверяет наличие файла "kolibri.img";
5. Если образ "kolibri.img" найден, происходит загрузка ОС в штатном режиме.
6. Если образ "kolibri.img" не найден - выдаётся ошибка с диалогом, предлагающим перезагрузку по нажатию любой клавиши и последующей перезагрузкой ПК по нажатию любой клавиши.

Требования:

1. Должна присутствовать обработка ошибок ввода/вывода, ошибок в связи с отсутствием или недостачей критических системных файлов ОС.
2. Атрибуты и регистр именования системных файлов должны игнорироваться (скрытые и файлы со смешанным регистром должны без проблем обнаруживаться загрузчиком).
3. При каждой перезагрузке прежнее содержимое памяти должно очищаться и перезаписываться новыми данными, считанными с физического носителя.

Функциональность:

1. Поддержка интерфейсов: IDE, SATA, USB.
2. Поддержка файловых систем: FAT16, FAT32 (в перспективе, возможны варианты).
3. Поддержка нескольких ОС на одном носителе: отсутствует (в перспективе, возможны варианты).
4. Поддержка загрузки с разделённым пространством физического носителя: единственный раздел, множество разделов с одним активным.
5. Поддержка обратной связи (желательно и опционально): происходящее может отображаться на дисплее вплоть до статуса загрузки каждого файла в динамический раздел.

---

Возьмётся ли кто-то за разработку и на каких условиях?
Буду благодарен в рамках поддержки проекта, в т.ч. материально (PayPal или Yandex.деньги) тому, кто возьмётся за разработку такого загрузчика
Помогу с тестированием на реальном железе, в этой теме разработка и отчёты по тестированию.
Предложения можно в личку.

Уже было
viewtopic.php?f=34&t=1158

Ознакомился с веткой. Есть следующие вопросы:
1. Что конкретно из описанного мной "было", когда было и в какой форме?
2. Автор, насколько я вижу, предупредил о том, чтобы в ветке больше не писали - из чего я сделал вывод, что разработка не идёт. Или я ошибаюсь?

Самое сложное - блок Функциональность.

Самый сложный из него - п.3 - это однозначное использование одного из существующих загрузчиков(grub, lilo, ..) или их переписывание (зачем?). В принципе, Колибри и так идёт в сторону "Линукс на ассемблере", так что...

Даже исключив п.3, задача здесь не столько написать загрузчик, сколько сделать полную переработку (= создание заново) всего блока кода по работе с драйверами, где драйвера диска (pdo, fdo) - частный случай. И, видев текущий код Колибри, есть подозрение что эта переработка заденет и другие подсистемы, вкл. диспетчер памяти и задач. А это 2/3 ядра. А если делать как надо, то и создание новой функциональности такой, как напр. ACPI......

У меня реализован почти весь этот функционал, но под х64, и кода там порядочно... Отдавать его всяким говнокодерам (не тебя имею в виду) я не планирую. И дело не в деньгах.

А это не вы участвовали в обсуждении новой ветки и переработки ядра?? Я помню, что где-то там была речь о переходе на x64...

У меня в пункте 3 указано "отсутствие" поддержки нескольких ОС, она не нужна.
Это связано с тем, что по моей задумке такой загрузчик (такая идея) будет использоваться только в рамках конфигурации с единственной ОС, чаще всего - на единственном винчестере, единым пространством.

delete

Две монеты
Вы либо не понимаете, о чём речь, либо некомпетентны. Я склоняюсь ко второму варианту.

Идея была, она не мне принадлежит.
Краткое содержание предыдущих серий ветки:
1. Есть штука, которая работает, пока ОС ещё не загружена, и умеет выполнять команду "прочитай файл с таким-то именем с той файловой системы того устройства, откуда идёт загрузка". Называется "первичный загрузчик". Точнее, есть несколько разных штук для разных вариантов загрузки - загрузка с FAT32 на выделенном разделе, загрузка с CD, загрузка с FAT12/FAT16, загрузка как вариант меню загрузчика Windows. Все они предоставляют один и тот же интерфейс. Они уже есть, работают, более или менее отлажены.
2. Далее появляются варианты.
2а. Один из вариантов - пусть штука из предыдущего пункта грузит непосредственно ядро, далее ядро может дочитать нужные файлы и что-нибудь с ними сделать. Сейчас есть вариант, когда ядро с помощью первичного загрузчика читает настройки из конфигурационного файла config.ini, потом с его же помощью грузит kolibri.img и начинает полноценную работу. Этот вариант, опять же, уже есть, протестирован и работает, требует только перекомпиляции ядра со специальной опцией.
2б. Можно встраивать создание kolibri.img непосредственно в ядро. Всё, что нужно написать, - создание образа из файлов, которые загружает уже существующий код, никаких усилий по работе с физическими устройствами не нужно. Исключительно вызовы первичного загрузчика и перетасовывание байт в памяти.
2в. Можно выделить из ядра код загрузочного экрана, который нужен только для инициализации и только занимает место при работе.
2г. Можно написать вторичный загрузчик, который, основываясь всё на той же готовой функции "прочти файл", умеет, например, показывать меню выбора различных систем, ядер или дистрибутивов, прописанных в файле конфигурации. В том числе необязательно Колибри.

Автор забросил разработку под Колибри.

_________________
Сделаем мир лучше!

Насколько я знаю из теории, загрузчик первого уровня расположен в тех самых 512 байтах загрузочного сектора физического носителя. Он выясняет таблицу размещения файлов носителя и передаёт управление загрузчику второго уровня, который и занимается дальнейшим: инициализацией оборудование, считыванием файлов и передачей управления ядру ОС.
Насколько я понимаю, у Колибри есть вот этот загрузчик второго уровня, который вы называете "первичным", умеющий передавать управление и нужные параметры ядру, которое дальше работает в соответствии со своей программой, загружая операционную систему.
Так вот проблема, как я понимаю, состоит в том, что вот этот "первичный" загрузчик ограничен в своих возможностях и накрепко заточен под загрузку ОС из образа. Как я понимаю, это связано с особенностью работой ядра, которое в силу исторических причин "кастрировано" в отношении формы обращения к файлам - поэтому и загрузчик в самом ключевом своём месте кастрирован и вынужден плясать под дудку ядра ОС.
Поэтому мы вынуждены выдумывать эту комбинацию сбора из отдельных файлов опять в образ, чтобы потом загрузчик смог общаться с ядром "на его языке".
Получается, что в итоге истинная причина в ограничении не загрузчика, а ядра - и из-за него загрузчик тоже, в итоге, ограничен сведением всего, что бы мы в нём не придумали, к формату, приемлемому для ядра ОС.
Примерно так?

Воу-воу-воу, палехче дорогуша )
Шучу.
Нельзя же так: говорили-говорили, вдруг - бабах, уже другое.
Вот из-за такой манеры излагать у многих форумчан крайне тяжело понять и разобраться.
Объясните, будьте добры, последовательно и обстоятельно, не срывайтесь с одного на другое.

Кто они? Где работают и где есть?

Если этот вариант уже есть - то, по логике, для осуществления задумки потребуется научить загрузчик (раз он такой умный и может обращаться с файловой системой) собирать kolibri.img из файлов на носителе, а в случае наличия уже имеющегося kolibri.img, отдавать приоритет свежесобранному.

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

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

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

Примерно так. Есть некоторые расхождения в деталях, но для этой темы они несущественны.

Нет. Первичный загрузчик ограничен в своих возможностях, что проявляется в следующем: он умеет загружать произвольный файл по имени и больше не умеет ничего. Ядро, собранное с extended_primary_loader=1, просит его загрузить файл по имени kolibri.img.

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


Есть несколько вариантов одной и той же штуки, которые совершенно разные внутри, но имеют одну и ту же цель, предоставляют одно и то же API - загружать произвольный файл по имени - последующим этапам загрузки, чем бы это ни было, и поэтому объединены под общим именем "первичный загрузчик". Так понятнее?

Различные первичные загрузчики. В папке kernel/trunk/bootloader/extended_primary_loader.

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

?

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

_________________
Сделаем мир лучше!

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

Я всю жизнь работал с dos, потом с windows и только недавно на macos перебрался.
Так вот, теоретически я помню, что в случае с dos загрузка ПК происходит так:
1. Происходит запуск первого сектора (те самые первые 512 байт) физического диска с первичным загрузчиком dos;
2. Первичный загрузчик dos загружает в память данные из первых трёх секторов (на которых располагается файл io.sys) и запускает их - начинает работать "вторичный загрузчик";
3. Вторичный загрузчик dos загружает оставшуюся часть себя в память, загружает драйвера и проводит их инициализацию, загружает ядро и проводит его инициализацию, обрабатывает конфиги и всё что указано в них и запускает консоль (разумеется, если ничего другого не было задано в конфигах).


Что же мешает устроить загрузку Колибри.ОС приблизительно таким же путём?
Почему нельзя организовать загрузку примерно таким образом:
1. первичный загрузчик (первый сектор) загружает данные из заданных секторов из файла на носителе и запускает этот код - дальше начинает работать вторичный загрузчик;
2. вторичный загрузчик загружает некий "дефолтный набор" драйверов устройств из файлов и проводит их инициализацию - после чего доступ к физ носителям на уровне файлов сможет быть обеспечен;
3. потом загружает ядро из kolibri.mnt и проводит его инициализацию, обрабатывает конфиги с параметрами и передаёт ядру управление.

Далее, разработать образ для загрузочного CD/USB-носителя, который бы при загрузке запускал разработанную программу установки Колибри.
В программе установки была бы возможность выбрать физический носитель, формат хранения ОС (образ kolibri.img или непосредственные системные файлы на носитель) и компоненты системы.
- Если был выбран формата хранения ОС в образе (чтобы, как Вы говорили, система за каждым чихом не смыкала винчестер) - программа установки собирает образ с выбранными компонентами и прописывает первичный и вторичный загрузчики образца №1 (рассчитаных на загрузку из образа) на заданный носитель.
- Если был выбран формат хранения ОС непосредственно системными файлами на носителе - программа установки записывает системные файлы на носитель и прописывает первичный и вторичный загрузчики образца №2 на заданный носитель.
Всех, у кого на выбранном носителе установлена другая ОС и добро на перезапись пользователь не даёт - программа установки шлёт к GRUB, объявляя что поддержки мульти-загрузки НЕТУ.
Пользователь перезагружает ПК - и запускается ОС.

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

---
P.S. есть просьба: не отвечайте, будьте добры, в стиле "не получится - никто не возьмётся" )))) Помогите предметно разобраться.

Драйвера вызываются последовательно, напр. в ситуации чтения файла с гибкого диска последовательность будет такой: приложение - ядро - fat12 - fdc. Это называется "стек драйверов". В общем случае в стек могут быть добавлены драйвера шифрования диска, кэширования, контроля доступа, RAID-контроллера и т.д. Основная сложность - порядок добавления драйверов в стек. Фактически, порядок добавления в стек совпадает с порядком загрузки и инициализации драйверов.

---

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

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

Между этими двумя способами большая разница: чтобы загружать драйвера системного диска с системного диска, Windows осуществляет загрузку драйверов системного диска в реальном режиме, затем переходит в защищённый режим, инициализирует драйвера системного диска и загружает прочие драйвера. Линукс (и Колибри) сразу переходит в защищённый режим, инициализирует находящиеся на initrd драйвера системного диска, после чего загружает прочие драйвера.

---

Теперь к целям и задачам. Какую из описанных выше схем вы хотите реализовать? Или вы хотите реализовать свою схему, отличающуюся от приведённых? Обе - это удвоение кода.

Не говоря о том, что в Колибри не существует понятия стек драйверов, а работа с драйверами реализована из рук вон плохо. И основная цель, как я её вижу, не перейти со схемы Линукс на схему Windows, а реализовать нормальную архитектуру драйверов что позволит сделать из монолитной системы с динамической загрузкой драйверов микроядерную.

io.sys - это и есть ядро. Естественно, ядро умеет инициализировать драйвера.

То, что во времена DOS рабочая среда совпадала с загрузочной, а сейчас - нет.

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

_________________
Сделаем мир лучше!

Товарища Две монеты я понял полностью.

Отвечаю на ваши вопросы:

1. Хочу реализовать замысел, приведенный в топике, а так же замысел приведенный в сообщении: нужен, во-первых, хороший установщик, который бы позволял гибко настраивать состав дистрибутива, а так же прописывал загрузочный сектор и загрузчик на диск, а во-вторых - процесс загрузки, реализованный на базе обращения к файлам, без образа.
Я-то, на самом деле, понимаю, зачем хитрюги соорудили этот кост... "фичу" с образом: чтобы выдавать высокую производительность ОЗУ за высокую скорость работы ОС, чтобы низкая скорость работы винчестера не ломала всю малину )))
Поэтому - понимаю, что для таких хитрецов формат хранения ОС в образе img должен оставаться. В конце-концов, Установщике ОС пользователь мог бы выбирать сам: например, если у него винчестер на жёстких дисках, его ОС будет шустрее работать из ОЗУ, а для флеш-памяти скорость обращения роли играть не будет, зато править конфиги, регулировать состав ОС и заменять отдельные файлы без необходимости лезть в образ будет глотком свежего воздуха.

2. Я планирую запускать Kolibri OS не только (и не столько) на современных устройствах, но и на самых древних и самых маломощных, слаборазвитых технически устройствах, где будет лагать и Linux.
Соответственно, важно и критично стремление к отсутствию в этой ОС "вывихов" и ковыряний в носу через анальное отверстие - ассемблер бесспорно сложен в написании, но одновременно сам по себе прям как доска в плане исполнения кода, из-за чего ПО работает практически мгновенно.
В этом я вижу главное и неоспоримое преимущество Kolibri ОС над остальными ОС.
Поэтому меня искренне печалит тот факт, что в попытке упростить РАЗРАБОТЧИКАМ дело, нагромождаются конструкции и обходные пути, которые, вроде бы, "упрощают дело", но в отдалённой перспективе такой подход приводит к неизбежной деградации кода.

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

Таковы лично мои основные замыслы и лично моё мнение.

---
К CleverMouse есть замечания/вопросы:

1. io.sys - это не ядро. Ядро - это msdos.sys. По крайней мере - в ms dos.

2. Если загрузчик вынесен в отдельный от ядра файл, то с точки зрения формальной логики он не может являться частью ядра. Неотъемлемость определяет, как раз, обратное: к примеру, файл io.sys в группе ОС Windows 9x представлял из себя вторичный загрузчик, который объединён с ядром в одном файле.
Давайте будем, всё-таки, менее небрежны в терминологии, чтоб не запутывать и без того запутанное дело.

3. Под "рабочей средой" вы подразумеваете защищённый режим памяти?

Вообще-то, нет. Если вам нужно загрузить напр. 10 файлов общим размером 100 кб, независимо от метода с диска 100 кб. А после загрузки файлов с диска в память, скорость во всех методах будет одинаковая.

initrd (init RAM drive) имеет следующие преимущества перед загрузкой драйверов по одному:
- чтение одного файал значительно упрощает загрузчик
- есть возможность записать initrd в ПЗУ, что позволит загружать ОС на бездисковых станциях

Есть и недостатки.

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



Вообще-то, нет.

Производительность по большей части определяется алгоритмами, а не их реализацией. Сравни: нужно вскопать 10 га, у меня трактор, у тебя - палка-копалка. Палка-копалка "проста как доска"... Тесты показывают, что выигрыш в производительности от перехода на ассемблер редко превышает 5-10%; разница в размере скомпилированного файла более ощутима, но по сравнению с ёмкостью жёстких дисков не критична.

---

Итого:
1. установщик
2. реализация схемы загрузки драйверов Windows в дополнении к схеме Линукс -- в общем бесполезно, но почему бы и нет?

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

Установщик это пара недель работы по 2-3 часа в день. Поставлю в список задач, когда лень заниматься другим. Но это не быстро...