RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : 2 OS/4 Team


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Slavik Gnatenko, 2:467/99
To : LightElf
Subj : 2 OS/4 Team
> > В целом так. Только тут надо уточнить, что это не налагает на линукс ограничения использовать на корневой точке монтирования всегда только FS, уже вкомпилированую в ядро. Это касается только начальной загрузки, а потом можно и перемонтировать. Когда линукс стартует с рамдиска и потом перемонтируется на что-то другое - это даже специальное название и кучку реализаций имеет: Initrd
> Ну собственно это никак не меняет того, что я сказал. Пингвиновое ядро уже имеет внутре себя драйвера/IFS для загрузки. Ему не нужно прыгать в RM и дергать биос. То бишь отличие в том, что линуху все подается на блюдечке. В момент старта у него уже есть драйвер и IFS для бутового раздела/диска. Соответственно все запары с BIOS/UEFI/OpenFirmware/OpenBIOS ложатся на бутлодер. Что, в общем-то, логично и правильно.
Оно не меняет, оно уточняет, что такая архитектура линукс ограничивает не сильно. А вот отличие не в этом. Осевое ядро точно так же получает на блюдечке эту пару. Драйвер диска находится в лодыре и доступен через известный хелпер, IFS в виде mFSD приходит образом модуля. Такой путь, как минимум, не хуже вкомпилирования их в ядро. Более неприятен более тонкий момент: лодырный хелпер считается RM кодом и в этот RM ядру надо прыгать самостоятельно. PM хелпера в этом интерфейсе нет, никому был не нужен. Можно сделать совсем небольшой правкой ядра.

> > А вот тут ты меня не внимательно читаешь. Разумеется, ядро это не парит. НО, осевое ядро это точно так же не парит. И что осевое ядро стартует в RM - это никак не связано с начальной файловой системой. Это просто так захотел IBM. Это можно даже изменить относительно локальной правкой ядра и сохранить интерфейс к mFSD, который вполне себе PM.
> Угу, а mFSD будет дергать Int13 в RM.
Не "будет", а "может". И не Int13, а ядерный хелпер, который будет дёргать лодырный хелпер. И тут уже с гибкостью неплохо.

> Теряется смысл mFSD как таковой. Если все идет через PRELOAD, то нафига mFSD? Сама логика ущербная, со времен OS/2 1.3 тянется. Ядро определяет, чего грузить и дергает лодер (а тот - BIOS Int13 в RM). Вообще, изначально предполагалось что os2ldr будет отдаваться OEM производителям в сорцах и те будут для своего железа писать свою вариацию. Ессно никто заморачиваться не захотел.
Я потерял мысль. Смысл mFSD в том, чтобы монтировать FS поверх абстрактного интерфейса к диску. В том числе и совсем полноценную, если хочется. На stage 1 такой интерфейс реализуется в лодыре, потом mFSD переключается на загруженый дисковый драйвер. А что должны были писать производители? Int13 они и так делали. Зачем что-то ещё?

> А вот в VESAFB сделано еще прикольнее. Там бутлодер выставляет видеомоду через BIOS и потом все живут в этой видеомоде, никуда из нее не переходя.
Занятно. Ну если допустимо засовывать в лодырь такую, в общем-то не свойственную ему функцию, то можно. И даже в оси реализовать, если хочется. Переписать BVH на вывод букв в графике и в панораме оторвать установку видеорежимов. А оно кому-то надо?

Sat 17 Aug 2013 02:06 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.