OSDev

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

Ну ведь - первичный 1, и совсем по названию другой - логический 1, все равно как на 1 листе 1 параграф, а не 5 параграф от начала произведения. Тут трудная дилемма сквозной или нет нумерации. Лично мне все равно как я и так и так пойму.

Думаю что основные и логические диски не должны нумероваться одним числом. Здесь мы имеем 2 цифры разных порядков, получаем что-то вроде
1.1
1.2
1.3
...
2.1
2.2
2.3
Номер должен быть комплексным числом из двух байт (по байту на число). Можно задействовать и буквы, как в Linux.
Вообще-то можно использовать кодирование одним байтом, где десятки являются номером раздела, а единицы номером подраздела.
11
12
13
...
21
22
23
Но каждый разряд имеет всего 16 значений, что является некоторым ограничением. Хотя для MBR достаточно, там всего 4 диска.

Эта схема подразумевает двумерный массив разделов, т.е. что любой раздел может иметь внутри себя логические диски, т.е. подразделы. Однако, это совсем не так. Во-первых, расширенных разделов не может быть больше одного. Во-вторых, расширенный раздел всегда последний. Т.о. на самом деле мы имеем одномерный массив, только он с изломом. Двумерность в данном случае избыточна и обманчива. Она подразумевает возможность существования разделов 1.2, 1.3..., хотя если у нас существует раздел 2.2, то подобных разделов уже быть не может.
Полноценная двумерность есть во FreeBSD, там есть подразделы.

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

Вопрос, даст что нибудь(улучшит или ухудшит) конвертирование утилитой mksys ядра FreeDOS при следующей цепочке загрузки. Первичная boot грузит конвертированный вторичный syslinux.sys а он по параметрам из syslinux.cfg грузит FreeDOS. Так вот ядро лучше оставить родное или конвертировать?
И аналогичный вопрос по всем другим конвертируемым ядрам.

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

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

Это верно, если не брать в расчет раздел "c". Кстати в GRUB'е, как ты знаешь, используется вложенная нумерация BSD-разделов, а вот для обычных разделов - последовательная "с изломом" перед номером первого доп. раздела внутри расширенного раздела DOS.

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

jarilo, нужно конвертировать, если загрузка ядра выполняется при помощи первичных загрузчиков Ёды и порядок загрузки, предусмотренный ядром, не соответствует загрузочным спекам Ёды (сейчас это любое стороннее ПО кроме моих "творений", полученных в результате самостоятельного конвертирования, насколько я знаю).

Я подразумевал, что

А всё перечислять конечно нужно 3-х значное число, или даже 4-х как в Multiboot Specification, чтобы уж на все случаи жизни.

Вышла версия 3.3.

В новой версии:

• Добавлена поддержка загрузчиков Microsoft Windows NT4.0, XP/64, WS2003/64, Vista, 7 утилитой mksys;
• Добавлена загрузка с ISO-образа на USB-носителе (USB-ISO);
• Добавлена загрузка с файловой системы exFAT;
• Добавлена загрузка с файловой системы Ext4;
• Добавлена загрузка с файловых систем Minix/Minix2/Minix3;
• Добавлен обход ошибки BIOS некорректной подмены номера загрузочного диска в FAT32;
• Устранена ошибка конвертирования ядра FreeDOS.

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

Заходим, скачиваем, пробуем.
http://goncharov.pp.ru/ru/osboot.htm

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

Описание впечатляет

Cool

На ЛСки отвечу чуть позже. (Какой именно "старый загрузочный сектор" нужен?) Что там было с конвертированием ntldr'а? Кстати недавно восстанавливал bootsect'ом экспишный загрузчик для FAT32 (на флешку для WinPE) и случайно заметил, что восстановление затронуло только первый сектор (хотя загрузчик трехсекторный с учетом FSInfo). Думал, что глюк, но WinPE запустилась успешно. Скорее всего ntldr догрузил себя сам. Если же код первого сектора способен загрузить ntldr полностью, то вопрос, для чего тогда нужен код третьего сектора.

По exFAT есть открытые спеки?