Загрузка первого байта первого сектора

Да? А что я писал о 84й строке?

 

Скажи, а зачем было нужно вообще изобретать этот велосипед? Коду в BS (boot sector) достаточно знать свой номер (смещение) относительно начала диска. И все, ему становится по барабану очень многое. Он автоматически становится (в твоих терминах) универсальным, и прекрасно будет работать будучи записанным в первый сектор носителя (BIG FDD, или как ты называешь "цельное устройство"), в первый сектор раздела, или вообще в файл который скармливается бут менеджерам от Windows NT / LILO / SYSLINUX.

А зачем? Точнее, какие данные нужны BS которые есть в ТР?

Знаешь, вот мой загрузчик никогда и не напрягался, и ни когда не надеялся на DS:SI, и прекрасно грузит, то, что должен грузить, и ему начхать, активен ли раздел, или нет. Он даже в ТР никогда не лезет. И DH ему твой не нужен. Все прекрасно работает и так.

Просто ребята, такое ощущение, что вы искусственно выдумали проблему, которой в принципе, не существует. И с успехом ее решаете.

 

Лично от себя могу сказать. Фишка в том, что я посчитал передачу номера ядру более универсальным способом, чем передачу смещения. Еще это обусловлено тем, что мое ядром может грузиться без использования вторичного загрузчика (сейчас это основной и вообще пока единственный способ, который я использую). Возможность загрузки с дополнительных разделов - это уже дополнительный бонус. Она стала прорабатываться по причине того, что ядро способно принимать в качестве входного параметра не только номер первичного раздела, но и номер дополнительного раздела. Это все специфично для моей оси. Я не прошу, чтобы кто-либо поддерживал данную технологию загрузки полностью. Но она многоуровневая. Если кто-нибудь увидит в ней что-то полезное для себя, то можно реализовать частичную поддержку. К примеру интерфейс "MBR-загрузчик-первичный загрузчик" с поддержкой только первичных разделов. Я развел тут дискуссию про EPR по той простой причине, что abcd008 как-то заикнулся, что тоже использует (собирается использовать) EPR для хранения кода, и совсем недавно сказал, что готов поддержать мою Boot Spec. (если не полностью, то по крайней мере по части упомянутого интерфейса). Изначально я об этом говорить не собирался.

Здесь опять-таки все завязано на номере раздела, который нужно передавать ядру. Если выполняется загрузка с неактивного раздела, то его номер нужно определять. Если же к примеру взять за идентификатор загрузочного раздела его смещение на диске, то достаточно данных из BPB или другой аналогичной структуры (если в структуре ФС вообще предусмотрено хранение смещения). Хотя опять можно вспомнить про то, что у дополнительных разделов внутри расширенного раздела типа 5 структура BPB хранит не совсем корректное смещение. Если не вводить какой-то механизм, позволяющий получать корректное смещение кодом первичного загрузчика в подобной ситуации, то первичные загрузчики дополнительных разделов вообще нельзя использовать для загрузки. Короче все взаимосвязано.

Поздравляю. Но видимо загрузку из дополнительного раздела ты не практикуешь... или используешь вторичный загрузчик.

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

 

Более универсальный способ, давно изобретен и реализован в самой первой IBM/MS DOS, которая знала про таблицы разделов. А своим изобретением, ты лишь потерял совместимость с другими бот менеджерами. И сделал его очень не универсальным. Такое конечно возможно, для домашних поделок и чисто для гимнастики ума, не спорю. Если это и есть само цель, то тогда ты во всем прав.

Так и не ответили на вопрос, а зачем?

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

Я слабо разбираюсь в твоих терминах, первичный загрузчик, вторичный загрузчик, третичный загрузчик......
Так что не знаю, что там я использую.

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

 

OK. Давай по существу...

1. Какие грабли? Конкретный пример напороться на эти грабли?

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

 

Давай. Но сначала ответь на простейший вопрос, не по ленюсь, и повторю в третий раз.
А зачем тебе вообще знать, с какого раздела ты стартуешь?

Самый простейший вариант. Если твоя ОС, а точнее код сидящий в БС нуждается в знании, номера раздела с которого она стартует, и не важно ссылку на запись ты передаешь, или номер раздела, и без этой информации стартовать не может, вот тут и появляются грабли. Во первых, ты привязываешься к собственному загрузчику. Использование чужого загрузчика, не знающего о твоих стандартах становится не возможным. Со всеми вытекающими последствиями. Во вторых, тебе придется создавать собственный бот менеджер, если есть необходимость устанавливать еще одну ОС, да еще в добавок проследить, что бы в процессе установки вторая ОС не потерла твой загрузчик. И в третих, ты совершенно не учитываешь тот факт, что MBR с ее ТР, уже начала отмирать.

Не понял вопроса.

 

Мне нужен системный диск/раздел/каталог. Из него читаются основные конфигурационные файлы, загружаются драйверы и т.д.

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

Код (Text):

1.   cmp byte [7DFFh],88h
2.   je @f
3.   mov dh,XX ; где XX - номер раздела
4. @@:

или сохранить номер раздела в файле на этом разделе и потом его считать в рамках специального первичного загрузчика можно в любой момент. Я уже не говорю о возможности использовать вторичный загрузчик, который сможет нормально работать без валидного значения DH на входе, хотя будет загружаться абсолютно по той же схеме, которую сейчас использует ядро (к моменту старта все необходимое для его нормальной работы будет уже находиться в памяти - сам вторичный загрузчик (boot.os) и его конфигурационный файл (boot.fs), содержащий сведения в том числе и о загрузочном разделе ядра). Короче схема очень гибкая.

Это более чем нормально. Любая система прежде всего ориентируется на свой загрузчик. Это уже дело универсальных загрузчиков подстраиваться под разные системы. Специально подстраиваться под GRUB и т.п. загрузчики я не собираюсь.

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

Учитываю. Моя схема элементарно адаптируется под использование GPT. В этом случае номер раздела будет соответствовать порядковому номеру дескриптора раздела в GPT.

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

 

Phantom_84
я уже писал. если ты не хочешь помечать расширенный отдел. то вариант только один:
код в mbr должен проверить все разделы на активность. и если нет активного, то передать управление единственному расширенному разделу(EBR)(и dh=5). соответственно проверив его на сигнатуру AA55h и наличие данных в первых байтах.

для EBR:
он не зависим от mbr.
надо проверить основной раздел(разделы на активность), если таких нет, то передать единственному расширенному управление(как в случае mbr) и к dh прибавить 1(inc dh) если поддерживается спецификация.

таким образом код будет работать. даже если ему не передают 88 и dh.


теперь о загрузке системы.
как я понял твоя грузит сама себя без BR.
но это дело вкуса. я считаю что br должен быть.
но как бы там не было, и как бы вы не говорили. система или загрузчик полюбому должен составить дерево дисков(разделов). и отсюда два способа узнать откуда нас грузят:
1. сравнить содержимое PT со значением по адресу ds:si или сразу взять значение из bpb.
наличие ds:si можно проверить также по bpb(поле тип диска. если жесткий то ds:si должно быть. или просто по номеру диска. если dl>80 то есть)
2. похож на первый но ускоряется тем что не сравнивает все PT тазделы.
а просто во время составления дерева, помечает раздел с номером DH как системный.

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

 

Phantom_84
Это более чем нормально. Любая система прежде всего ориентируется на свой загрузчик. Это уже дело универсальных загрузчиков подстраиваться под разные системы. Специально подстраиваться под GRUB и т.п. загрузчики я не собираюсь.

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

я в своей системе(точнее загрузчике(не BR, а лоадер)) собираюсь использовать два способа. первый через свой загрузчик, второй по multiboot spec.

загрузить любую систему можно элементарно. либо передать управление на ее BR или загрузить файл(если знаешь какой) загрузчик, или сразу ядро если оно соответствует multiboot spec.

 

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

А вот это как раз говорит, что в логике ОС допущена грубая ошибка.

[дальше опять много умных слов и терминов не понятных для меня, по этому скипнул]

Да ни хрена она не гибкая. Если шаг в сторону, от надуманных и никем не поддерживаемых стандартов, то возникают "некоторые ограничения".

Типичный подход свойственный русским программистам. Сделать так, как удобно им, и начхать на удобство пользователя. А потом долго думать, почему их продукт, кроме них самих никому не нужен. Хотя еще на этапе проектирования, можно было не выдумывать велосипед, а сделать грамотно, и удобно для пользователя.

Это не нормально, и это проблема.

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

А ты реально пробовал эту ситуацию моделировать?

Все равно не понял вопроса. В смысле как мой загрузчик узнает с какого раздела его запустили? Да ни как. Ему это по барабану.

 

Хорошо. Только у меня DH=5 уже явно указывает на первый дополнительный раздел внутри расширенного, как на загрузочный. Чтобы код EPR самостоятельно определял дополнительный загрузочный раздел, передаваемое ему значение DH должно находиться в диапазоне 0-4. Второй вопрос, как именно код EPR будет самостоятельно определять дополнительный загрузочный раздел. Вариант с поиском дополнительного раздела, имеющего в своем дескрипторе установленный признак активного раздела, имеет право на существование, но как я уже сказал, о такой возможности не говорится ни единого слова в описании формата расширенного раздела. Может, хранить номер загрузочного дополнительно раздела (5-255) в EPR в байте перед таблицей разделов? Тогда, если MBR-загрузчик явно передает номер дополнительного загрузочного раздела (5-255), то в EPR выполнять его поиск и загружаться с него, а если MBR-загрузчик "не определился" с этим (не нашел активного первичного раздела, но нашел расширенный раздел с EPR-кодом и хочет его "попросить" поискать загрузочный раздел среди дополнительных разделов внутри расширенного), то в EPR самостоятельно определять загрузочный дополнительный раздел и загружаться с него.

Не понял, зачем увеличивать dh.

Принимается. Правда, не все MBR-загрузчики будут передавать управление в EPR. Те, которые не проверяют тип (активного) загрузочного раздела, это делать будут (вообще это их недочет, но здесь он будет нам на пользу). Те, которые будут знать о новых возможностях, естественно будут и передавать управление в EPR, если ее обнаружат. А вот те, которые предусмотрительно проверяют тип (активного) загрузочного раздела, этого делать не будут. Например, Alter не позволяет выполнить загрузку с расширенного раздела:

Код (Text):

1.         or al,[si+PTREC.type]
2.         jnz short @f
3. err_pt:
4.         call putstr
5.         nb 13,10,"Incorrect type of boot partition",0
6. @@:
7.         cmp al,5
8.         je short err_pt
9.         cmp al,0Fh
10.         je short err_pt

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

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

 

Прежде чем это говорить, вы бы озвучили какую-нибудь вменяемую альтернативу моему подходу. Только не надо говорить о RAM-диске (к чему, не наступив на грабли, сразу становиться на костыли) и о хранении идентификатора системного диска/раздела на самом диске/разделе (я выполняю установку системы в том числе и путем переноса файлов на отформатированный под мою систему диск/раздел без внесения каких-либо изменений в эти файлы).

А что ее моделировать. Потребуется заменить пару компонентов, не входящих непосредственно в ядро. Речь пока идет о типичном для BIOS порядке загрузки, но только на основе GPT, а не PT. С порядком загрузки на основе UEFI пока детально не разбирался, но думаю, будет не намного сложнее. Другое дело, что у меня ядро сейчас ориентировано на BIOS-интерфейс, поэтому об использовании EFI пока говорить не стоит.

Можно поподробнее.

 

Меня интересует не столько сам загрузчик, сколько программа, которая им загружается. Если вы опять скажете, что у вас структура более продуманная, поэтому и загружаемой программе этого знать не нужно, то потрудитесь объяснить, как такое возможно. Или программа настолько проста, что ей действительно эта информация просто не нужна?

 

Здесь есть одно незначительное НО. Чтобы EPR-коду не нужно было повторно считывать MBR для определения положения расширенного раздела (эта информация нужна, т.к. внутри расширенного раздела типа 5 смещения относительные - их нужно корректировать), лучше использовать дескриптор расширенного раздела, на который указывает DS:SI. При наличии 88h будет значительно больше гарантий корректности этого указателя.

 

А никто и не говорит про RAM диски. "идентификатора системного диска/раздела на самом диске/разделе" а о чем тут речь, я не понял вообще. А сам подход реализован еще в прошлом веке, посмотрите любой BOOT сектор от IBM/MS DOS. Просто вы не захотели ответить на вопрос, "а зачем нужно знать номер загрузочного раздела". Только ответив на этот вопрос, ответ на ваш вопрос становится очевидным.

Ну чисто так на досуге, подумай, как твоя система отличит, что сидит в DH. А потом смоделируй ситуацию, когда первый раздел сидит до границы 2Тб, второй раздел эту границу пересекает, а третий и четвертый целиком сидит за этой границей . И тебе нужно загрузится с любого раздела. Мой подход позволит это сделать, а вот твой? Только без изобретения еще одного велосипеда.

Что бы ответить подробнее, нужно понять, что же ты спрашиваешь. Я пока не понимаю.

 

Вот теперь становится несколько понятней.
Задача кода сидящего в BR загрузить в память некий другой код, назовем его загрузчик, находящийся внутри раздела.
Для этого нужно знать, смещение этого кода относительно начала диска. А оно как ни странно есть сумма двух смещений. Первое, это смещение самого раздела относительно начала диска, которое в частности DOS берет из самого BS. Второе, это смещение кода относительно начала раздела, которое DOS в частности вычисляет анализируя файловую структуру. Есть и второй способ, в самом BS прописывается смещение загрузчика, относительно начала раздела/диска. У каждого способа, свои плюсы и свои недостатки. Про реализацию первого способа, можно подсмотреть в коде BS от MS DOS. Про реализацию второго способа можно посмотреть в исходниках SysLinux.

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

Как вы видите, и программе, (в моих терминах загрузчику) знать из какого раздела он стартует совершенно не нужно.

 

Зы )))

Простите, а у вас "код, сидящий в BR" (я использую вполне устоявшийся термин "первичный загрузчик"), будет выполнять окончательную загрузку (загружать ядро, драйверы)? Судя по всему нет, т.к. вы сказали, что этот код грузит "загрузчик, находящийся внутри раздела" (я использую вполне устоявшийся термин "вторичный загрузчик"). Тогда для выполнения дальнейшей загрузки вам необходимо передавать смещение раздела из первичного загрузчика во вторичный. А вот тут уже становится интересно. Каков должен быть формат этого смещения? Еще детальнее какова должна быть размерность этого смещения? 32 бита? Но ведь ваш подход позволяет грузиться с дисков, превышающих размер 2 Тб (ничего, что не дословно цитирую? ). Тогда видимо вы передаете как минимум 64-разрядное смещение раздела ))) А я всегда передаю 8-разрядный идентификатор раздела! И мне "по барабану", каков размер диска! Укладывается ли он в 2-терабайтный предел или нет. Он вообще может быть "безграничного" размера ))) А ввести дополнительное поле для хранения этого 8-разрядного идентификатора в структуру, хранящуюся в BR (BS), или просто пропатчить код первичного загрузчика непосредственно перед загрузкой или еще на этапе форматирования раздела я смогу всегда. Уже по второму кругу это объясняю. Короче моя схема опять элементарно адаптируется под ситуацию загрузки BS нестандартным способом (к примеру из файла).

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

 

Нет и не собирается. Задача "первичного загрузчика" загрузить "вторичный" загрузчик, и не более того.

Да. 80Бит.

Зациклились наверно. А где именно зациклились, а показал ниже.

Если это поле уже есть, то зачем его еще и передавать, и проверять на валидность переданное значение? Работа ради самой работы?
И зачем парится с разбором ТР и прочего на этапе работы "вторичного" загрузчика? При моем подходе это совершенно не нужно. Уже позже, на этапе "третичного" (а такой термин у вас устоялся?), я делаю разбор ТР и прочего, и подгружаю необходимые драйвера.

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

 

Для меня главные две предпосылки. Первая, это Удобство конечного пользователя.

И немного о терминах.
"Нулевой" загрузчик, загрузчик, который вызывает первичный, типичный пример это код в MBR или BOOT менеджер.
"Первичный" загрузчик, типичный пример, код сидящий в BS, и загружающий "вторичный" загрузчик.
"Вторичный" загрузчик, некий модуль, с которой начинается загрузка самой ос. Как пример, часть кода в IO.SYS или в ntldr.

Первичный загрузчик, должен знать место, где живет вторичный загрузчик. А это возможно указать тремя способами.
1) Некая динамическая структура формируемая в процессе работы нулевого загрузчика. Частный случай патч кода первичного загрузчика нулевым загрузчиком.
2) Некая статичная структура живущая внутри первичного загрузчика, и формируемая или на этапе создания файловой системы, или на этапе установки системы.
3) Динамическое формирование этой структуры в процессе работы.

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

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

 

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