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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > В целом так. Только тут надо уточнить, что это не налагает на линукс ограничения использовать на корневой точке монтирования всегда только FS, уже вкомпилированую в ядро. Это касается только начальной загрузки, а потом можно и перемонтировать. Когда линукс стартует с рамдиска и потом перемонтируется на что-то другое - это даже специальное название и кучку реализаций имеет: http://en.wikipedia.org/wiki/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 на вывод букв в графике и в панораме оторвать установку видеорежимов. А оно кому-то надо?

__, _,_ __, _,_ _, \|_) \| \| \| \ \| / /_\ \| \ \| \| \|_/ \|/ \| \| ~ ~ `~' ~ ~ ~ ~