OSDev

А что мешает строить приложение с базовым адресом в старших адресах, а не в младших?

Мы не только о физическом размещении говорим. Если бы мне не нужен был первый мег для других целей, то, отказавшись от уплотнения "рабочих" секций внутри файла ядра, я бы мог их физически оставлять в базовой памяти, но в ВАП все равно размещать вверху. Мне реально релокация ядра пока не нужна (достаточно возможности менять базу ядра путем его перекомпиляции), хотя когда-то была идея иметь переменный размер прикладного пространства в зависимости от тек. потребностей ядра, но пока я этого не сделал.

Невозможность изменения этого базового адреса без перекомпиляции всех приложений.

Надеюсь, ты же не собираешься писать ОС со своим форматом исполняемых файлов, в котором присутствует жёсткая привязка к адресам. Если так, то это типичный пример плохо спроектированной ОС. И PE, и ELF нормально релокируются. А самому ядру релокируемость не требуется при любой организации адресного пространства.
Повторю - принципиальных соображений в пользу top-half в нормально спроектированной ОС нет, плохо спроектированной и top-half не поможет, а разводить здесь религиозную войну мне не хочется.


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


Вот этого не знаю. С EUFI пока что плотно не работал.

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

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

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

Вот и получается, что ты твою систему обобщаешь на вообще. Если что-то плохо для тебя, это не означает что это вообще плохо.
Предлагаю завязать с этим религиозным оффтопом.

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

Нет, ну я ведь сказал, почему это плохо. Если для тебя это не важно, так и скажи. Уверен, другим не все равно, делать релокацию постоянно вхолостую или не делать. И хотят ли они тащить в экзешник релоки в обязательном порядке.

Поддерживаю.

Ещё раз: что мешает строить прикладные программы с базовым адресом в старшей половине адресного пространства, а не в младшей? Никакого перемещения не потребуется ровно так же, как в случае с построением по нижним адресам (естественно, в этом случае при условии, что внизу сидит система).

Не важно. Всё виртуальное адресное пространство принадлежит разработчику ОС. И ни какие BIOS UEFI о нём не знают и с ним не работают.

По поводу куда мэпировать. Лучше в верх. Фантом правильно написал. Проще ядро поправить чем каждую пользовательскую программу. А пользовательскую вы и не поправите пока её сторонний разработчик её сам не поправит. Согласен с SII что нужно делать релоки. Но ОС должна подстраиваться под программы, а не наоборот. иначе причинно следственная связь нарушается. ОС ставит ограничения приклодная программа диктует свои требования. И вот после ОС уже исполняет эти требования. Иначе архитектура портиться, в том смысле что становиться запутонее и сложнее.

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

О перекомпиляции речь не идёт, а релокации необходимы в любом случае. Без релокаций нельзя эффективно разместить динамически подключаемые библиотеки.

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