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

Ну я так и понял.

Хорошо. На перспективу, так сказать )))

Зря ты это сказал. Ну да ладно.

Не "вторичного", а первичного - того, что находится в загрузочной области раздела (BS+). Первоначально система могла грузиться только с активного раздела (первичные загрузчики просто делали mov dh,0; пропатчивание было возможно, но толку от него было бы мало). Вторичный загрузчик не использовался (предполагалось, что передавать dh!=0, а также использовать загрузочный каталог, отличный от корневого, будет именно он). Затем мне понадобилось загружать мою систему с неактивного раздела. Я это сделал опять без использования собственного вторичного загрузчика, отчасти и из-за того, чтобы по минимуму влиять на порядок загрузки, использовавшийся на каждом конкретном диске до установки моей системы в один из разделов этого диска (речь прежде всего идет об обеспечении нормального функционирования, свойственного обычным MBR-загрузчикам; размещаемые в MBR первичные загрузчики GRUB, Lilo и т.п. в расчет не беру - их можно разместить и в другом месте). Так первый раз была применена технология альтернативной загрузки, выполняемой MBR-загрузчиком. Но расширенный интерфейс "MBR-загрузчик - первичный загрузчик" еще не существовал, поэтому приходилось "париться", пока не был введен данный интерфейс (как вариативный). Почему не остановился на варианте хранить номер раздела в его BS, как единственном и достаточном? Есть одна причина, по которой лучше не хранить номер раздела в BS этого раздела (или где-либо еще в разделе). Сами догадаетесь, какая?

Аналогично. И что вы тогда о моей терминологии говорили, как о какой-то особенной?

MBR-загрузчик (stage 0) - тоже самое, только для меня это все-таки обычно не весь бутменеджер, а только первая его часть, находящаяся в самом первом секторе диска.
Первичный загрузчик (stage 1) - тоже самое, только здесь немного наоборот - это не только код BS, а код вообще всей загрузочной области раздела (в современных ФС первичный загрузчик обычно занимает более одного сектора).
Вторичный загрузчик (stage 2) - тоже самое, только некоторые бутменеджеры совмещают в себе функции в том числе и вторичного загрузчика.

Разницы между 1 и 3 не уловил. Но я фактически тоже самое и делаю в интерфейсе "MBR-загрузчик - первичный загрузчик". Только динамически пропатчиваю загружаемый BS не непосредственной записью нужного значения, а сигнатурой, указывающей на то, что нужное значение находится в определенном регистре. Второй (пропущенный) вариант - это фактически тот запасной вариант, говоря о котором я уже начал "зацикливаться" ))) (Слово "повторяться" имеет тот же смысл, но прозвучало бы в ваших устах не так грубо.)

Да нет же. Пока что первичный загрузчик для своих личных целей использует поле Hidden Sectors (кстати в NTFS оно расширено до 64 бит), а номер в DH транслирует от MBR или формирует сам (но не использует). Номер использует уже ядро, сопоставляя с теми номерами, которые возвращает менеджер томов (сейчас используется "PT-соглашение" в нумерации разделов, но никто не запрещает хоть сейчас использовать "GPT-соглашение" - ядру до лампочки смысл номеров - оно знает только о том, как нужно трактовать нулевое значение, а точнее какие действия в этом случае следует предпринимать).

 

Phantom_84
ты немного не понял. MBR может передать только 1-4 в случае активности основного раздела.
но если он обнаружит что активный расширенный, или активных нет, но есть расширенный раздел. То он должен передать ему управление(проверив сначало наличие там кода) и dh=5.
5 потому, что это первый расширенный раздел.

а вот EBR должен проверить внутри себя наличие активного основного раздела. если он найдет, то просто передаст управление на BR(этого раздела), а dh уже будет рано 5 и его менять не надо.
в противном случае, если нет активного(как и в mbr), передать управление следующему EBR(расширенному разделу)
и к dh прибавить 1(чтоб dh уже указывал на следующий раздел).

все элементарно.

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

 

Ну не на перспективу, а от лени, если честно. Один пень больше 48 бит не нужно на сегодняшний момент, а для красоты 64 бита.

Тут действительно описался.

А термины я не зря ввел, что бы исключить неверное толкование ниже сказанного. А вот ты на это не обратил внимания. И не последовал моему примеру. По этому и возникают высказывания типа: "Вторичный загрузчик не использовался" "Я это сделал опять без использования собственного вторичного загрузчика", то есть получается искусственная путаница, создаваемая тобой. Так к взаимопониманию мы никогда не придем.

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

Да. Абсолютная бесполезность этой информации, в следствии ее не нужности.

Нет, это я взял вашу терминологию, и чуть ее уточнил, о чем уже писал в начале поста.

А разница с том, что 1, это информация переданная из предыдущего загрузчика, а 3, это самостоятельно вычисленная в текущем.

И все, что ниже, это очередное закапывание грабель, и создание новых трудностей.
Посмотрите относительно новый механизм монтирования томов в юниксе. Монтирование по положению на шине и номеру разделу уже отмирает, и оставлено только для совместимости. Я про например монтирования HDA5 на точку /home. Даже XPюша уже монтирует свои тома не опираясь на эту информацию.

 

В смысле первый дополнительный раздел внутри расширенного?

Я все "логические диски" внутри расширенного раздела называю дополнительными разделами. А вложенные расширенные разделы так и называю.

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

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

 

Идея abcd008, более правильна, чем твоя. вот только ее доработать, и будет вообще сказка.
Помечаешь первичный расширенный раздел активным, и даже если сидящий в МБР загрузчик не пропатчен, то он тупо передаст управлению в первый сектор расширенного, считая, что там сидит BS. Что и нужно для поставленной задачи А если пропатчен, то тем более .

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

 

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

Ну да монтирование по гуидам - это такой же пользователь-ориентированный способ монтирования разделов, что и сохранение в BS вашего 10-байтного смещения начала раздела ))) Давайте про монтирование разделов на "точки" говорить не будем, тем более приводя в качестве примера "ХРюшу". У меня структура VFS отличается и от виндов, и от никсов. В ней изначально поддерживалось монтирование на "точки" не только целых разделов, но и отдельных каталогов, а на имена самих разделов не накладывалось никаких существенных ограничений (вы их можете именовать и по "географическому" принципу, и по гуидам или вообще дать им имена, совпадающие с кличками ваших домашних питомцев). Принцип именования разделов может различаться в разных версиях менеджера томов, могут совмещаться совершенно разные принципы именования в одной и той же версии менеджера. Пользователь сам может указать, как нужно называть тот или иной раздел. И т.д.

 

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

Я любой "уровень вложений" обрабатываю одним и тем же кодом EPR. Мне не зачем в каждое звено этой вложенной цепочки вписывать отдельный экземпляр EPR-кода. Кстати, вы это ручками собираетесь делать? Потому что на сегодняшний день не существует ни одного стандартного средства для этих целей. Только hex-редактор )))

 

Разве? Я вроде ее уже назвал:

Не нужно путать мягкое с теплым. UUID это UUID, и цель у него одна. А смещение, это смещение, и цель у него совершенно другая. И кстати, судя по вашим словам, вы то же не брезгуете пользоваться смещением сохраненным в BS, но почему-то не называете его "гуидом", и активно используете. Так что не будем передергивать.

А почему нет?

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

Да и про ХРюшу.
Хотите отмапить раздел на букву? Да в легкую.
Хотите отмапить каталог на букву? Да в легкую.
Хотите отмапить раздел на каталог? Да в легкую.
Кстати, еще в досе это было возможно сделать.

 

Как вы все любите усложнять....

Да, именно. Потому что так проще в реализации.

А чем плохо? Места на диске будет больше занимать?

Точно так же как и вы.

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

 

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

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

MisHel64
ты не прав когда пишешь EBR один для всех дополнительных дисков.
он такой же как и mbr. тогда зачем вообще тебе писать EBR, если можно впихнуть все в MBR(они же одинаковы по размеру).
поэтому я и говорю что в каждом дополнительном разделе должен сидеnь свой(а не общий) код EBR.

вот и надо думать:
1. использовать как подтвердил MisHel64. помечать всю цепочку как активную.
2. использовать мой метод основываясь только на присутствии одного расширенного(дополнительного) в PT
3. тоже что и 2, но еще и с использованием DH

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

 

Phantom_84
А если нужно загрузиться не с 5-го, а к примеру с 25-го раздела? То тогда конечно нужно проверять признак активности у дополнительных!!! разделов с 5-го по 25-тый ))) Я не говорю, что нельзя помечать расширенные или дополнительные разделы активными. Я говорю, что не встречал упоминания о такой возможности хотя бы в одном описании, поэтому не использую этот способ задания загрузочного раздела.
-так ты наверно и такого вида загрузки не встречал?
я не пойму только одного, ты dh вычисляешь и передаешь?
или оно тебе заранее известно и служит не для системы, а для указания MBR(EBR) какой раздел грузить?
если последнее, то я тебе не помошник.


Я любой "уровень вложений" обрабатываю одним и тем же кодом EPR. Мне не зачем в каждое звено этой вложенной цепочки вписывать отдельный экземпляр EPR-кода. Кстати, вы это ручками собираетесь делать? Потому что на сегодняшний день не существует ни одного стандартного средства для этих целей. Только hex-редактор )))
-раз небыло такого способа, нет и программ для этого.
но если ты пишешь систему, то можешь и прогу для этого написать)
а код не должен быть только один. так как разделов несколько...и у каждого свой код.

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

для этих целей надо написать установщик, который будет проверять наличие свободного места. либо после mbr(обычно есть еще 62 сектора), или в конце диска(почти 8 метров)

 

Специально жирным пометил.

А зачем выполнять двойную работу?

Ты меня не с кем не спутал? И кстати, что ты этой фразой сказать то хотел?

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

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

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

 

Открой для себя мир BB кодов, а то читать твои посты довольно затруднительно.

 

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

Умной системе и так до фонаря, откуда ее грузят. И анализировать всю цепочку ей вовсе не обязательно. А вот на счет Dl уже я очень дано объяснил, причем не однократно, почему ей и это должно быть до фонаря.
-анализирует она для создания дерева всех разделов.
dl-меня еще не подводил. да и как еще ты в BS можешь узнать номер диска.
если ты пишешь систему, то ей нужны файлы во время загрузки. а как ты их загрузишь не зная номера диска и раздела.
с разделом проще. но диск он всегда должен передаваться. а если его не передает какой либо левый mbr(как ты сам говоришь надо придерживаться стандарта) то это уже не мои проблемы. за всех отвечать не должен.

 

В ядре номер раздела я использую скорее как гуид, чем как смещение. Хотя суть все равно одна - идентифицировать раздел для дальнейшей работы с ним. Непосредственно ядро не пользуется смещениями. Оно обращается к разделу точно также, как к цельному устройству - по имени (виртуального устройства). Единственное отличие разделов от цельных устройств заключается в том, что одна из функций устройств хранения в одном из полей спец. структуры, идентифицирующей физическое местоположение устройства, возвращает ненулевое значение - тот самый номер раздела. Когда ядро ищет загрузочное виртуальное устройство (чтобы смонтировать на нем локальный корень или псевдоудаленный корень //boot/ ), оно сравнивает номер раздела из BDI (если он не нулевой) со значением соответствующего поля. Если в BDI был передан нулевой идентификатор раздела, ядро проверяет, захвачено ли соответствующее цельное устройство управляющей структурой типа "менеджер томов". И если это так, то обращается к одной из функций менеджера томов, захватившего устройство, для получения дефолтного загрузочного раздела (активного раздела), на котором и пытается смонтировать корень. В противном случае пытается смонтировать корень непосредственно на цельном устройстве.

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

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

В EPR я его передаю, чтобы EPR-код не пытался самостоятельно определять, с какого дополнительного раздела выполнять загрузку. Но это не единственно возможный вариант. Он уже работает, но только при наличии 88h и dh=5-255 на входе EPR. Есть еще вариант с наличием 88h и dh=0-4, а также, как ты верно заметил, без наличия 88h и соответственно какого-либо валидного значения dh. В этом случае я предлагаю, чтобы EPR-код самостоятельно пытался определить загрузочный дополнительный раздел (и вычислял значение dh, если он будет сообщать первичному загрузчику соответствующее значение и сигнатуру 88h). Ты можешь это делать на основе анализа признаков активности в дескрипторах дополнительных разделов. Я могу использовать номер, сохраненный в EPR, по аналогии с MBR.

Я уже говорил, что давно бы так и сделал, если бы хватило места в MBR.

Во, во. Jumbo так и делает, только он использует в качестве вспомогательной части код, сохраненный в EPR, а не в дополнительных секторах после MBR.

 

abcd008 Мужик, но начни пользоваться BB кодами. Чужие цитаты выделяй или тегом "quote", или хотя бы италикой.

А ты много бут менеджеров пробовал?

Телепатически. И этот способ меня еще никогда не подводил.

Согласен.

Ответ можно найти например посмотрев на код BS от MS DOS.

 

Вот это вот твой не до чет. Ты делаешь различие между "цельным устройством" и "разделом".
Я лично этого не делаю. Unix то же не делает, но прозрачно это маскирует. Windows то же не делает. Даже ДОС древнейший отделяет мух от котлет и предоставляет два уровня абстракций. Один для работы с логическим диском (или как сейчас называют "томом"), а второй для работы с физическим диском (то что ты называешь "цельным устройством"). Теперь и понятно, почему ты придумал именно такой термин. По этому вся философия описанная ниже, есть и следствие вот этой непродуманности, и реализации велосипеда.

Про //boot у тебя опять сказка про белого бычка. Не нужен для этого номер раздела. Повторятся не буду.

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

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

 

в этом наши мнения разошлись. я собирался передавать dh ядру, чтоб она знало свой номер, а mbr и ebr просто его вычисляли.
а в передаче dh ebr я точно не нуждаюсь, не вижу смысла.

это как?

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

я уже писал, мои загрузчики всегда передают параметры биоса по цепочке, и они всегда дойдут до BS(загрузчика).
и в таком случае не нужно писать разные BS для разных дисков(hdd/fdd/cd), они будут работать, будто им передал управление сам bios

 

Специально выделил жирным ключевое слово.

 

а причем тут раздел, и твое недоверие DL?