OSDev

При написании самопального загрузчика у каждого своя мотивация. Разработкой ОС обычно занимаются люди интересующиеся низкоуровневыми деталями работы компьютеров. Поэтому одна из причин разработки собственного загрузчика - просто чтобы разобраться с тем, как оно работает. Для обычной настольной ОС загрузчик типа GRUB вполне пригоден.

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

У меня мотивация к написанию загрузчика возникла после дискуссии здесь на форуме. В итоге я тоже потратил какое-то время на разработку загрузчика. Детали можно посмотреть здесь. http://dev64.wordpress.com/2012/04/04/fat32-boot-loader-2/. Так как на эксперименты с ОС у меня лишь небольшая часть времени, мне эта разработка помогла вспомнить как оно программируется на ассемблере.

А где здесь сторонники такого подхода? Возможно, Станислав со временем придет к более дружелюбному для пользователя способу установки.

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

Переключаться в PM в первичном загрузчике как-то не готично.

Загрузчик от слова ЗАГРУЗКА, простенькая функция от биоса чтения секторов с кодом с диска в память, которая либо не работает либо работает. Если осталось место на первом секторе, котроый грузит биос то его можно использовать как угодно.

У меня так получилось по "историческим причинам". До переключения в защищенный режим, всё работает в 16-ти битном режиме. Я когда делал сборку ядра, не сразу разобрался как можно линковать 16-ти битный код вместе с 32-битным. По этой причине, ядро сделал сразу работающим в защищённом режиме.

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

Я не уверен, что ядро, которое я реализую само уйдет далеко от вторичного загрузчика (если достигнет хотя бы, уже будет более чем), поэтому сделал переход в защищённый режим в загрузчике. Ничто не мешает грузить в загрузчике не ядро, а вторичный загрузчик. Получится стандартная многоступенчатая схема. Вынести из загрузчика переход в защищённый режим - не сложно. Ломать - не строить
Переименуем kernel в stage2 и lets go. Спасибо за коммент однако.

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

От человека, который грузит систему, как "MBR-helper" и думает, что это предел совершенства, ничего другого ожидать не приходится. Как верно было подмечено, нужно выполнять четкое разделение функций между разными сущностями, даже если внешне они видятся единым целым (загрузочный образ). Разъяснять на пальцах это утверждение я не буду. Просто скажу, что лучше будет оставить "место на первом секторе" пустым, чем тянуть туда что попало.

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

Мне нравится Как вариант, это можно делать, используя промежуточное звено в виде ОС-специфичного вторичного загрузчика.

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

Было время, когда я выносил в отдельный модуль (расширитель ядра) часть ядра, которая была не нужна на начальных этапах инициализации, однако я отказался от такого разделения (возможно, временно), т.к. сейчас ядро достаточно компактное.

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

Лолшто?

Искать файл в ФС дольше? Не смеши меня, ты не заметишь разницы даже на первом пне.

Первые 2 раздела - для восстановления? Всю жизнь хватало одного. А то, что они в принципе присутствуют - ничего не меняет. Как и их расположение. В MBR у меня груб, и, если я сотру к чертям разделы с виндой, то раздел с линуксом останется, и груб будет грузиться как ни в чём не бывало.

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

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

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