Board.KolibriOS.org

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

В основной конфигурации не используется, потому что это ломает текущую схему загрузки, а я, в отличие от VaStaNi, предпочитаю как-то загружаемую и нормально работающую систему вместо идеально загружаемой, но не работающей. При включении определённой переменной в конфиге, начиная с http://redmine.kolibrios.org/projects/k ... sions/1962 , вполне используется.
API реального режима, потому что используется оно в реальном режиме.
Логический адрес загрузочного раздела лежит в совершенно стандартном месте по [7C00+1C], это определяется не загрузчиком, а структурой BPB. Естественно, если загрузка шла не с CD, на котором вообще с разделами довольно плохо.

_________________
Сделаем мир лучше!

Как это ПОИСК??? Эт, что то ты дружище, не туда кажись...
BPB конкретной файловой системы, на конкретном разделе находится, конкретного диска!
Какой еще поиск? Мы ведь всю эту цепочку пропахали, прорыскали, нашли каталог, нашли в нем файл (хош ядро, хош образ) и загрузили его в пямять и запустили.... но + передали ему все то, чтем обладали, ИМЕЛИ, работая в BPB!
А имели мы:
номер диска,
тип ФС,
номер кластера оглавления диска искомого каталога ОСи (т.е. это уже путь типа "C:\KOLIBRI\" или
если роднее так, типа: "/hd0/KOLIBRI/")
Неразумно это не передать ядру (ОСи), раз оно состоялось фактически (запущено физически и работает, способно получить).
Разве нет?
Зачем еще поиск? Ну сверка, ну проверка, ну расширенно пошарить, понимаю, но - "поиск подходящей ФС" ?
ИМЕННО ИСПОЛЬЗУЮ!
загружаемся этими BPB не с "корня" а со "своей" папки в корне:

/fd0/KOLIBRI/kernel.mnt
или
/hd0/KOLIBRI/kernel.mnt
/hd1/KOLIBRI/kernel.mnt
/hd2/KOLIBRI/kernel.mnt
...............
не вижу проблем на переходный период грузиться и так
/hd0/KOLIBRI/kolibri.img

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

Есть USB флешка,
нужно на второй раздел FAT16 поместить или инсталлировать Колибри ОС и отдать человеку,
чтобы он пришел домой, воткнул ее в свой ноут и загрузился в этой оси,
предварительно включив в BIOS грузиться с флеш USB HDD.
И еще.

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

Спасибо.

Трудно что-то возразить.

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

Это вариант, если идентифицировать раздел по его смещению на диске. Есть ли возможность связать этот параметр с логическим именем раздела в системе?

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

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

VaStaNi
Потирая красные глаза Легко:

sed 's/use_lba = 0/use_lba = 1/' kernel/trunk/bootloader/extended_primary_loader/fat1x/bootsect.asm
fasm kernel/trunk/bootloader/extended_primary_loader/fat1x/bootsect.asm bootsect.f1x
fasm kernel/trunk/bootloader/extended_primary_loader/fat1x/kordldr.f1x.asm kordldr.f1x
echo -e 'lang fix ru\nextended_primary_loader = 1' > kernel/trunk/lang.inc
fasm kernel/trunk/kernel.asm kernel.mnt
dd if=/dev/sdb2 of=bootsect.f1x bs=1 skip=3 seek=3 count=87 conv=notrunc
dd if=bootsect.f1x of=/dev/sdb2 bs=512 count=1 conv=notrunc
mount -t vfat /dev/sdb2 /media/flash_for_kolibri
cp kordldr.f1x /media/flash_for_kolibri/
cp kernel.mnt /media/flash_for_kolibri/
cp kolibri.img /media/flash_for_kolibri/
umount /media/flash_for_kolibri

Это установка загрузчика и копирование нужных файлов. Если нужно ещё сделать второй раздел загрузочным, то дополнительно parted /dev/sdb set 2 boot on и, возможно, придётся выдирать нормальный mbr из того же parted или setmbr.
Прочитать об особенностях загрузчика можно в http://redmine.kolibrios.org/projects/k ... loader.txt . Прочитать о fasm можно в мануале по fasm, который идёт в комплекте с компилятором. Прочитать о командах sed, echo, dd, mount, cp, umount можно, соответственно, в man sed, man echo, man dd, man mount, man cp, man umount.
Phantom-84, на этом этапе загрузки физически не существует полноценных драйверов устройства, и код в принципе может работать только через BIOS. Int 13h в защищённом режиме не особо работает.

_________________
Сделаем мир лучше!

Это в колибри команды такие есть? Не знал.
И на USB пропишется прямо из ОС колибри?

Нееее... Смотри. Типовая задачка.
Есть 4 диска у каждого 4 одинаковые папки в корне, пусть KOLIBRI
Надо посмотреть содержимое каждой. Чем они отличаются?
Локацией на диске и геометрией раздела диска, да?
Тогда, имея номер кластера(от нам проще "по ходу" достается из FAT) мы запросто и быренько их "осмотрим", без глобального поиска от рута.можно и так. Например в регистре передать указатель на стоку "/hd1/kolbri /" с учетом, что сегмент всегда = 0

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

Логическая ошибка файловой системы на диске. Нет?

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

В таком написании да.
у каждого из 4х хотел написать...
словом кластер этот, при работе получен. А это уже инфа.О чем и пишу...

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

_________________
Сделаем мир лучше!

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

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

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

Phantom-84, я выспалась и поняла, о чём ты. Действительно, ты прав, в принципе необходимо прорабатывать драйвера файловых систем для основной работы и их API в частности. Но в данный момент код файловых систем глубоко встроен в ядро и я не готова ни выковыривать их оттуда, ни даже планировать этот процесс. Соответственно, и обсуждать API, когда никто не готов что-либо делать, преждевременно.

_________________
Сделаем мир лучше!

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