Board.KolibriOS.org

Posted: **Tue Jul 26, 2011 7:40 pm**

CleverMouse wrote:Куда уж унифицированнее...

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

Posted: **Tue Jul 26, 2011 8:00 pm**

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

Posted: **Tue Jul 26, 2011 8:29 pm**

Phantom-84 wrote:--- какая файловая система на этом диске(с целью применить ядром нужный драйвер, конкретной FS этого диска);
+1, хотя я для загрузочного диска/раздела подсказки не использую - чистый autodetect - все равно проверки нужно делать, а драйверов ФС на момент детекта загружено немного, поэтому поиск подходящей ФС не так уж сложен.

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

Phantom-84 wrote:А вот это уже интересный момент... Как я понял, ты непосредственно в первичном загрузчике системный каталог не используешь, т.к. грузишь ядро из корня

ИМЕННО ИСПОЛЬЗУЮ!
загружаемся этими BPB не с "корня" а со "своей" папки в корне:

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

Posted: **Tue Jul 26, 2011 8:39 pm**

CleverMouse wrote:мой пост тоже является ответом и это уже реализовано.

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

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

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

Спасибо.

Posted: **Tue Jul 26, 2011 9:15 pm**

CleverMouse wrote:В основной конфигурации не используется, потому что это ломает текущую схему загрузки, а я, в отличие от VaStaNi, предпочитаю как-то загружаемую и нормально работающую систему вместо идеально загружаемой, но не работающей. При включении определённой переменной в конфиге, начиная с http://redmine.kolibrios.org/projects/k ... sions/1962 , вполне используется.

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

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

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

Логический адрес загрузочного раздела лежит в совершенно стандартном месте по [7C00+1C], это определяется не загрузчиком, а структурой BPB. Естественно, если загрузка шла не с CD, на котором вообще с разделами довольно плохо.

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

VaStaNi wrote:Как это ПОИСК??? Эт, что то ты дружище, не туда кажись...

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

ИМЕННО ИСПОЛЬЗУЮ!
загружаемся этими BPB не с "корня" а со "своей" папки в корне:

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

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

Posted: **Tue Jul 26, 2011 9:32 pm**

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

Code: Select all

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 в защищённом режиме не особо работает.

Posted: **Tue Jul 26, 2011 9:46 pm**

CleverMouse wrote:Прочитать о командах sed, echo, dd, mount, cp, umount можно, соответственно, в man sed, man echo, man dd, man mount, man cp, man umount

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

Posted: **Tue Jul 26, 2011 9:48 pm**

Phantom-84 wrote:"номер кластера" - это тоже не слишком "унифицированный" вариант - лучше передавать имя каталога

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

Phantom-84 wrote:Как вариант имя загрузочного устройства передавать в полном имени системного каталога, а не в отдельном идентификаторе, но этот вариант мне нравится меньше.

можно и так. Например в регистре передать указатель на стоку "/hd1/kolbri /" с учетом, что сегмент всегда = 0

Posted: **Tue Jul 26, 2011 9:57 pm**

CleverMouse wrote:на этом этапе загрузки физически не существует полноценных драйверов устройства, и код в принципе может работать только через BIOS. Int 13h в защищённом режиме не особо работает.

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

VaStaNi wrote:у каждого 4 одинаковые папки в корне, пусть KOLIBRI

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

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

Posted: **Tue Jul 26, 2011 10:07 pm**

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

В таком написании да.

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

Posted: **Tue Jul 26, 2011 10:09 pm**

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

Posted: **Tue Jul 26, 2011 10:15 pm**

VaStaNi wrote:у каждого из 4х хотел написать...

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

CleverMouse wrote:1) Легко...
2) ...и все необходимые для его функционирования вещи, типа поддержки USB и API для прямой записи на диск

Да, тогда первый вариант действительно кажется легким

...Хотя если писать эмуль для запуска никсов в Колибри

Posted: **Wed Jul 27, 2011 1:27 am**

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

Posted: **Wed Jul 27, 2011 1:48 pm**

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

Posted: **Wed Jul 27, 2011 4:16 pm**

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

Board.KolibriOS.org

Какие на данный момент есть наиболее приоритетные задачи?

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи

Re: Какие на данный момент есть наиболее приоритетные задачи