OSDev

Странно. Кинь, пожалуйста, в личке архивом твои коры с указанием конкретных версий.


Да не, я не планировал полноценный загрузчик для произвольной позиции, в ГРУБе уже есть. Я только выложил свой инструментарий для разработки в один клик, как обещал здесь. Разве есть какая-то практическая потребность его развивать?

Попытался разобраться с загрузкой виндового bootmgr и понял одну вещь. Вот, вроде бы предусмотрены уже два независимых механизма идентификации загрузочного раздела, но, похоже, не хватает ещё одного. Надо бы в регистрах ECX:EAX передавать номер первого сектора раздела (оно же - количество скрытых секторов).

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

OK.

Я стараюсь не использовать GRUB (или любой др. вторичный загрузчик) без крайней необходимости. Особой потребности нет, но я использую rawfs-загрузчик в небольшом разделе, входящем в состав позиционно независимого образа, причем даже с FAT12/16 (в этом случае возникает необходимость в использовании всех перечисленных мной параметров).

Я когда-то на эту тему вел настоящие словесные баталии с одним товарищем. Мой основной аргумент - это не универсально. Конечно сложно сказать, когда мы достигнем необходимости использовать нумерацию секторов большей (чем 64) разрядности, но это наверняка случится. Поэтому, если уж и вводить такой параметр, то его нужно делать расширяемым. В моей оси применительно к отдельных файловым операциям я так и сделал. Кстати упомянутый товарищ мне сообщил, что он использует 80-разрядный номер начального сектора раздела. Я уж не стал спрашивать, куда он такой номер сейчас передает. Простой 8-разрядный идентификатор раздела этим не страдает. Его единственное ограничение - это максимально возможное количество идентифицируемых разделов. Но я считаю, что ограничения в 255 разделов более чем достаточно для любых вменяемых применений, как сейчас, так и в будущем.

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


Если говорить о передаче номера, то мой аргумент примерно следующий. Вкупе с номером диска для самых примитивных ОС, к тому же работающих в реальном режиме, это позволяет однозначно идентифицировать раздел и приступить сразу же к разбору файловой системы, минуя разбор таблицы разделов. Так, виндовый загрузчик хочет в BP указатель на BPB/BS. Это очень просто сделать, имея номер первого сектора, но по идентификатору (или даже по геометрическому номеру) уже сложно. Идентификатор раздела, который передаётся в EBX, полезен в том случае, если у нас весь парсер дисковой подсистемы работает в защищённом режиме (особенно в 64-битном) и удобного доступа к функциям BIOS уже нет. А в более примитивных случаях он неудобен.
Если говорить о разрядности, то к тому времени, когда 64-бит на номер сектора не хватит, загрузка через BIOS (в реальном режиме) уже вряд ли будет в каком-либо виде актуальна.
Одно напрягает. И так утрамбованный до безобразия код надо трамбовать ещё, чтобы выделить место для нескольких инструкций.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Сначала я его использовал исключительно для "сырого раздела", но потом сообразил, что после небольшой доработки (оставив резерв под BPB+) при определенных условиях его можно использовать и для FAT12/16, ведь я все равно пакую в образе загрузочные модули последовательно без фрагментации. Можно конечно использовать и обычный загрузчик для FAT12/16, т.к. EBR-код все равно настраивает поле HiddenSectors динамически, но он не так компактен.

В общем я не спорю, что это вполне достойный способ идентификации раздела без необходимости доступа к его содержимому. Я когда-то передавал в первичном загрузчике сигнатуру, подтверждающую наличие BPB+ по известному адресу, но уже давно убрал соответствующий код и из первичных загрузчиков, и из вторичного загрузчика/ядра (за ненадобностью; оставил только небольшую лазейку для возврата к такой возможности в виде параметра, передаваемого вторичному загрузчику: BX - значение, отличное от 0xAA55; значение 0xAA55 как раз и указывало на наличие определенной структуры в памяти). У меня такого никогда не было, чтобы нужно было сразу пытаться обращаться к разделу по его смещению на диске. Я сначала создаю объект раздел (в ядре это виртуальное устройство), а потом уже осуществляю взаимодействие с этим объектом. Кстати идентификатор в виде номера стартового сектора раздела мне еще не нравится и тем, что из-за ошибки он может содержать и какой-либо другой номер сектора, и даже если он содержит корректный номер стартового сектора, а лог. структура самого раздела/тома некорректна, то при выполнении различных операций возможен выход за пределы пространства раздела, т.е. повреждение содержимого др. разделов.

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

И это тоже. Я понимаю твое стремление сделать как можно более универсальный интерфейс, но все-таки ты должен прежде всего ориентироваться на потребности твоей ОС. Я поступаю именно так. Лично тебе нужен такой идентификатор?

Да, в общем, не проблема.


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


Если файловая система побита компьютерной молью, то это по-любому катастрофа. Но с точки зрения загрузчика я проблемы не вижу. Если есть фатальные проблемы, то ядро просто не будет загружено. Либо же оно будет загружено, тогда ФС более-менее жизнеспособна. Это уже дальнейшая забота ядра, что делать с больной ФС, но по-любому, разумные ядра всегда сначала всё монтируют read-only и только в случае, если всё ОК, разрешают запись.


В выборе между 32 и 64 битами, как видишь, у меня никаких сомнений не возникает .


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Точно.

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

Да, только не забывай, что это требует введения доп. интерфейса MBR-VBR и/или хранения 64-разрядного идентификатора внутри бутсектора.

В плане универсальности для меня лично значительно более актуальной является загрузка первичным загрузчиком двух файлов. Да, конечно, когда ты использовал только лэйбльный идентификатор, это было тоже большой проблемой, но географический номер раздела и номер начального сектора раздела не являются лэйбльными идентификаторами, поэтому для меня разница между ними значительно менее существенна, хотя конечно спасибо за то, что ты в первую очередь реализовал мой способ идентификации разделов. Много идентификаторов сразу - это тоже плохо - у людей может появиться желание проверять их непротиворечивость. С другой стороны номер стартового сектора раздела не страдает ограничением, касающимся общего количества разделов на диске. А ограничение, касающееся размера диска, при использовании 64-разрядной нумерации пока не актуально.

Я попробовал в моем MBR-загрузчике сделать следующее:

Но не получил от твоего первичного загрузчика номер раздела в dh. Ты изменил интерфейс между MBR и VBR?

Так у меня уже 64-разрядные номера секторов, ещё со второй версии. Причём, всё проверено и отлажено на практике.


Да, мала-мала увеличил надёжность аутентификации после нашего с тобой обсуждения. Надо:

Вообще, потихоньку прихожу к выводу, что пора замораживать спецификации. Надо будет интерфейс MBR/VBR тоже документировать.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Это понятно. Я говорил о поведении твоих первичных загрузчиков при использовании сторонних MBR-загрузчиков, т.е. когда "родной" интерфейс недоступен. Допустим, при 32-разрядной нумерации секторов ты еще можешь использовать поле HiddenSectors, расширяя его нулями, но как быть, когда используется 64-разрядная нумерация? Это же относится и к 8-разрядному идентификатору. Мои первичные загрузчики имеют возможность передавать корректный идентификатор раздела даже в случае использования стороннего MBR-загрузчика. А твои? Перенесу сюда вопрос, заданный на буржуйском форуме:


Работает: cdbootse-mbremu-alter-3-jed-cdrom.zip. Обнулил соответствующую ячейку в ядре sys-grubldr-2.0, который находится на третьем разделе, и успешно загрузился (раньше в такой ситуации GRUB ругался).

Можно и не открывать. Это прежде всего интересно разработчикам MBR-загрузчиков (которых очень мало), а первичных загрузчиков у тебя и так внушительный комплект. Я сомневаюсь, что кто-то будет писать для тебя какой-нибудь недостающий первичный загрузчик, хотя вместе со спеками можно попробовать опубликовать шаблон первичного загрузчика, использующего твой интерфейс. Или ты собрался продвигать MBR/GPT-загрузчик?

Кстати ты когда-то говорил, что в твоих первичных загрузчиках можно легко изменить базу загрузки. Если это по-прежнему так, можно я подправлю ntfs- и ext-загрузчик под нужную мне базу? И еще один вопрос: ты реализовал доп. точку входа в ntfs-загрузчик по смещению 256h?

Что-то я не замечал. А зачем тебе вообще первый сектор? Ты разве его не отбрасываешь? Или для детекта используешь? Я сверял бинарники по смещению 200h всех трех версий с исходниками - все точно. Немного напрягает, что в версиях 1.99 и 2.00 строку с "префиксом" перенесли в запакованную часть бинарника, но в принципе я все равно обычно использую стандартный префикс "/boot/grub", а когда дойду до возможности установки этих версий в качестве вторичного загрузчика моей системы, научусь переносить эту папку на загрузочный диск.