OSDev

Добавлю: для системы должно быть абсолютно без разницы, сколько именно ОЗУ на компьютере (если, конечно, имеется минимально необходимый объём) и где именно оно располагается. Собственно, на то виртуальная память и предназначена, чтобы "отвязаться" от физической...

Была у меня такая идея (сделать размер user space динамически изменяемым в зависимости от текущего размера kernel space, т.е. потребностей ядра и драйверов), но пока я ее не реализовал, хотя и взял на заметку. Ядро загружается, начиная с позиции, заданной при компиляции, в "середине" ВАП (обычно это 2 гб или 3 гб; система 32-разрядная), затем драйверы. Само ядро в принципе не трудно разместить в конце ВАП, но вот с драйверами (в текущей их реализации) есть одна проблема. Дело в том, что каждый драйвер загружается в непрерывный участок kernel space и при выходе из процедуры инициализации возвращает ядру один параметр - скорректированный размер необходимого ему пространства (это было сделано для того, чтобы с минимальным участием драйвера увеличивать или уменьшать размер необходимого ему пространства в зависимости от его потребностей; естественно размер пространства корректируется ядром с конца и драйверы об этом знают). Если я откажусь от этого механизма, т.е. оставлю за драйверами перераспределение их пространств и дам им возможность выделять участки в том числе и перед базовым адресом загрузки, то драйверы можно будет загружать в ВАП и в обратном порядке.

+1. Я не использую ни один предопределенный адрес физической памяти выше отметки 1 мб. Такое возможно только когда ядро грузится GRUB'ом, т.к. он не может загрузить что-либо в базовую память, потому что использует ее исключительно сам.

Почему ж только с GRUB'ом? Что мешает свой загрузчик написать, если есть желание/необходимость?

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

А, теперь въехал... Я думал, что речь о системах вообще, а предыдущая фраза -- лишь для иллюстрации принципа в одной из конкретных самописных осей.

Что интересно, GRUB-2 таки умеет грузить ядро ниже 1МБ, у меня грузит на адрес 0x80000. Первый не умел.

Мне этого мало. К тому же не хочу делать привязку к GRUB 2.

Чтобы не маяться дурью используют релокации. Второй раз с матюгами будут перелопачивать, когда окажется, что младших двух гигов в 32-битном адресном пространстве задачи прикладному ПО категорически не хватает. Правда в Long mode таких проблем уже нет.
Вообще-то я придерживаюсь того мнения, что объём системной памяти в адресном пространстве задачи, должен быть настраиваем. Также, моё ИМХО в том, что прикладой задаче должен отводиться максимум пространства.


Да, это верно. Сам проверял. У меня нормально грузит на 600h.


У меня двухсистемное ядро. Грузится как ГРУБ-2, так и обычным загрузчиком 0-го уровня. Никакой привязки нет, поддерживается ради стандартов и мультизагрузки.

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

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


+1. Это один из пунктов моего "to do", причем уже очень давно. Но пока есть вещи и поважнее.

Я имел в виду, что не хочу, чтобы что-то работало только с GRUB 2, но не с GRUB (1). А ваши и 80000h, и 600h - это все не то. Вот скажите, какой объем памяти доступен для загрузки ядра, начиная с адреса 600h? Я конечно проверю, но что-то сильно сомневаюсь, что GRUB 2 перемещает себя в расширенную память прежде чем загрузить ваше ядро по адресу 600h. А у меня вообще адрес загрузки ядра совпадает с адресом загрузки GRUB. Я конечно не претендую на то, чтобы GRUB грузил мое ядро по этому адресу, но т.к. он сам находится в базовой памяти (как я думаю), он не сможет предоставить мне практически полный объем базовой памяти (в перспективе) для загрузки моего ядра (и еще одного модуля).

От первого ГРУБа пора отказываться. Убогий он.


Весь.


Перемещает :)

ЗЫ
Юбилейный, сотый пост! :)

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