OSDev

Слишком жёстко что-то фиксировать -- ИМХО, нехорошо. В частности, любой нормальный загрузочный модуль должен быть перемещаемым (ну или позиционно-независимым). В Винде, собственно, так и есть, просто у большинства ЕХЕшников таблица перемещений удалена, из-за чего они становятся неперемещаемыми (тем не менее, технически использование перемещаемых ЕХЕшников там поддерживается). Так что надо просто делать поддержку перемещаемых модулей, а в документации чётко оговорить: базовый адрес загрузки приложения предсказать невозможно, поэтому полагаться на него нельзя. Если после этого какой-то придурок сделает неперемещаемое приложение -- это его проблемы; такое приложение должно быть выброшено на свалку, и всё (желательно вместе с автором).

Что же касается траты времени на перемещение, то эта не шибко большая проблема. Во-первых, приложение можно строить в предположении, что оно будет грузиться с какого-то достаточно большого адреса, и ОС, если только имеется такая возможность, должна грузить такое приложение именно с этого адреса; все накладные расходы в такой ситуации сводятся к проверке возможности выделения необходимого объёма виртуальной памяти с данного адреса -- а это мизер по сравнению со всем остальным. Но и в том случае, когда перемещение потребуется, расходы на прибавление базового адреса загрузки и выполнение других действий, связанных с перемещением, будут ощутимо меньше, чем время физической загрузки приложения с внешнего носителя, т.е. скорость запуска приложения будет по-прежнему определяться в первую очередь временем, потребным на его поиск и загрузку.

Кстати, если обнаружен файл другой версии ОСи - можно его проапгрейдить при первом запуске (релокнуть на "стандартный" для данной версии адрес), и в дальнейшем он снова в большинстве случаев не будет перемещаться. А если это PosIndependentCode - проблем вообще нет.

Дело ваше. Я имел удовольствие наблюдать прецедент перелопачивания всей системы (включая все приложения!!!) из-за того, что кто-то вовремя не увидел "серьезные плюсы" размещения ядра выше прикладного пространства. Думаю, в случае чего смогу найти несколько "приятных слов" и в ваш адрес.

Есть варианты. Например, общаться с этим процессом из других процессов через IPC. Ты лучше скажи, зачем тебе тождественное отображение вообще нужно. Тогда, исходя из этого, может, и более удачное решение сможем подобрать. Что касается последнего вопроса, то суть не в том чтобы отображать ядра в верхних адресах, а в том, чтобы отображать ядро над прикладным пространством. При необходимости можно подвинуть ядро еще выше (или даже увеличить размер виртуального пространства, поддерживаемый системой), тем самым расширив прикладное пространство. С ядром это сделать значительно проще, чем с приложениями.

Чисто из любопытства, о каких проблемах "отображения в конец" идет речь?

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

Не вижу проблем делаем ядро в начале. Затем код пользовательских программ. Релокацию сделать не проблема. Как для первых так и для вторых.

Я запутался. :-( Так может оно вызвать серьезные проблемы или нет?

Как ни располагай, никаких проблем никогда не будет (конечно, если система в целом нормальная).

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

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

Это все понятно, но если этого вообще можно избежать, то почему бы это не сделать. Думаю, я достаточно обосновал свою точку зрения. А что вы выберете, дело ваше.

1. Норма -- это вовсе не обязательно то, что принимается и используется большинством. Например, в Средневековье большинство, причём абсолютное, "принимало и использовало" кучу всяких глупостей вроде гвоздей, которыми-де распяли Христа, да и сейчас не шибко лучше...

2. Выбрасывать таблицу перемещения является нормой в Винде. Вы ж вроде как не её клон создаёте?



Да, обычно они являются избыточными. Однако их наличие никаких проблем не создаёт (ну, занимает выполняемый модуль на диске несколько больше места, и что с того? размеры кода давно стали занимать мизерный объём от общего количества хранимых данных, и их разрастание на несколько процентов ни на что не влияет), а вот их отсутствие -- может создать. Так что с наличием таких данных будет надёжнее. Другое дело, что, выделив достаточный объём памяти под ядро, можно быть уверенным в отсутствии каких-либо проблем на ближайшие 100 лет (быстро растут объёмы обрабатываемых данных, но не объёмы кода и данных ядра -- там как раз всё довольно скромно, и даже нынешние гигабайтовые потребности объясняются не реальными нуждами, а больше быдлокодингом и впихиванием в ядро всего подряд).



Не удастся избежать проблем со 100% гарантией, причём именно наличие информации о перемещении даёт наибольший шанс на то, что программа всё же будет работать.

Ну а обоснование вполне достаточное, тут согласен.

Смысл в том, что ядро размещается не на каком-то фиксированном адресе (например 512 гигов), а просто с другого края, и заполняет память не с снизу вверх, а сверху вниз.