Yoda писал(а):
Чтобы не маяться дурью используют релокации. Второй раз с матюгами будут перелопачивать, когда окажется, что младших двух гигов в 32-битном адресном пространстве задачи прикладному ПО категорически не хватает. Правда в Long mode таких проблем уже нет.
Может, и будут, только зачем. Хотя лично мне сильно не нравится в Колибри, что там в исполняемом файле хранится вершина стека. Получается, что стек начального потока приложения нужно определять либо сразу после BSS (понятия резерва пространства вроде бы там нет вообще, только BSS), либо в минимально возможной вершине прикладного пространства (тогда озвученное тобой может иметь место), ну или либо где-то "по середине", но это вообще изврат. Мне такое не грозит, потому что у меня даже в самом простом исполняемом формате (кстати в нем поддержки релокации нет вообще) хранится только размер стека (минимальный и максимальный), а ядро всегда прикладные стеки размещало в конце прикладного пространства, каков бы не был его размер, поэтому у меня все приложения нормально работают и на G1-ядре, и на G2-ядре, причем пространство распределяется оптимально, просто для универсальности в исполняемом файле разметка секций должна быть описана с расчетом на минимальный размер прикладного пространства, а разница между минимальным и текущем размером может быть использована для динамического резервирования пространства, ну и про библиотеки забывать не стоит.
Цитата:
Вообще-то я придерживаюсь того мнения, что объём системной памяти в адресном пространстве задачи, должен быть настраиваем. Также, моё ИМХО в том, что прикладой задаче должен отводиться максимум пространства.
+1. Это один из пунктов моего "to do", причем уже очень давно. Но пока есть вещи и поважнее.
Цитата:
Да, это верно. Сам проверял. У меня нормально грузит на 600h.
...
У меня двухсистемное ядро. Грузится как ГРУБ-2, так и обычным загрузчиком 0-го уровня. Никакой привязки нет, поддерживается ради стандартов и мультизагрузки.
Я имел в виду, что не хочу, чтобы что-то работало только с GRUB 2, но не с GRUB (1). А ваши и 80000h, и 600h - это все не то. Вот скажите, какой объем памяти доступен для загрузки ядра, начиная с адреса 600h? Я конечно проверю, но что-то сильно сомневаюсь, что GRUB 2 перемещает себя в расширенную память прежде чем загрузить ваше ядро по адресу 600h. А у меня вообще адрес загрузки ядра совпадает с адресом загрузки GRUB. Я конечно не претендую на то, чтобы GRUB грузил мое ядро по этому адресу, но т.к. он сам находится в базовой памяти (как я думаю), он не сможет предоставить мне практически полный объем базовой памяти (в перспективе) для загрузки моего ядра (и еще одного модуля).