А это идея - выбрасывать редкоиспользуемые страницы в видеопамять, когда свободная оперативка заканчивается.
Вообще то я думал размещать в видеопамяти обои, шрифты и прочие картинки. Но идея интересная. В принципе ее можно реализовать но там где много видеопамяти, оперативки тоже хватает. rabid rabbit
Почему бы прямо не написать - давайте использовать модель памяти Windows NT?
Подобную схему памяти использует не только NT но и другие системы в разных вариациях. Она проста а значит меньше шансов сделать ошибки при написании кода. И достаточно удобна. Видеопамять и отображаемые на память порты ввода-вывода лежат в верхних адресах, так что логично переместить систему вверх и не дробить адресное пр-во ядра на несколько частей. Еще одно преимущество - все дескрипторы используют нулевой базовый адрес - можно спокойно передавать данные в ядро помещая их в стек и передавая указатель например в ebp - не надо вычислять смещение адресного пр-ва задачи относительно ядра.
halyavin
Ситуация такая: я отделил загрузчик от ядра, теперь это отдельная программа. Он использует текстовый ini-файл, где прописаны основные настройки. Загрузчик определяет размер установленной памяти, загружает ядро по физ.адресу 0x10000, дискету по адресу 0х10 0000, создает таблицы страниц, переходит в защищенный режим с включенной страничной адресацией и передает управление ядру.
После включения страничной адресации физ.адреса 0х0 - 0х00FF FFFF отображаются на линейные 0x8040 0000 - 0x813F FFFFF. LFB отображается прямо на адреса видеопамяти. Первая команда ядра начинается по лин. адресу 0x80410000, приложения грузятся с лин. адреса 0х0100 0000, адреса ниже пока зарезервированы для обнаружения ошибок. Работает большая часть программ кроме тех, что используют read/write_process_memory и IPC.
Пока не работают: Shootdown/Reboot, FDC и Vesa1.2 видеокарты. Сейчас я отлаживаю код для динамического выделения памяти в ядре и пишу код который будет делать доступной всю видеопамять.
Сейчас kernel.asm начинается с org 0x80410000. Оказалась довольно сложно компилировать вместе код загрузчика который должен работать в первом мегабайте и код ядра, который должен работать по старшим адресам. Сейчас загрузчик работает только с дискетами там простой код для разбора FAT12. Для загрузки с HD можно сделать отдельную версию - еще лучше модифицировать существующие загрузчики добавив код для инициализации системы. Нынешний дистрибутив расчитан на загрузку с дискеты, загрузчика с HD там нет моя версия не сильно отличается. В принципе можно сделать загрузчик который ничего не будет "грузить" - просто настраивать систему, если все файлы будет грузить в память другая программа.
Добавив код для инициализации системы? С переходом в защищённый режим, настройкой таблицы страниц и т.д.? А размер кода, который на это понадобиться? Ну ладно meosload, там нет ограничений на размер. Ну ладно mtldr, там ограничение в 8 Кб, до чего ещё долго. А односекторный acroboot? Кроме того, это означает добавление кучи кода, а ведь есть такие факторы, как банальная лень и ещё более банальная нехватка времени...
Проблемы с компиляцией, как правило, можно решить. А вот переписывать кучу существующего внешнего кода...
Да, и ещё: что, удалён код настройки параметров (синий экран загрузки показывается 16-битным загрузочным кодом)? А если в результате неудачно выбранных параметров система просто не загрузится? В текущей версии в этом случае просто изменяем параметры в синем загрузочном экране. А для редактирования файла настроек нужна как минимум загруженная ОС.
Добавив код для инициализации системы? С переходом в защищённый режим, настройкой таблицы страниц и т.д.?
Точно так. Размер загрузчика 7.5 Кб ядра 77 Кб. Синий экран настройки никуда не пропал. Исчез выбор MTRR (это будет по дефолту где есть) и источник загрузки (дискета, диск C:\ - все равно не работает). Добавлены текстовый ini-файл. Сейчас готовлю код для сохранения измененных параметров настройки в ini.
Похоже, что в mtldr не влезет. В acroboot - тем более. Не говоря уже о том, что дублировать синий экран в нескольких загрузчиках вряд ли целесообразно. Короче, загрузке с жёсткого диска наступит полная хана.
В общем, лично я решительно против идеи выделения загрузчика в отдельную программу/файл (если кто ещё не понял )
Serge
Мне интересна вот какая вещь.
Вот загрузили мы ядро, запустили систему. А что с той областью памяти, где располагался загрузчик? Мне кажется, его можно с чистой совестью затереть, как только запустилось ядро.
diamond
Из твоих размышления я все же не понял, почему загрузке с жесткого диска хана? Сформулируй идею в менее расплывчатом виде.
Мне интересна вот какая вещь.
Вот загрузили мы ядро, запустили систему. А что с той областью памяти, где располагался загрузчик? Мне кажется, его можно с чистой совестью затереть, как только запустилось ядро.
Я уже об этом думал. Сейчас он располагается по физ. адресу 0x60000. Этот адрес я выбрал произвольно. У меня эта область не используется. Но в принципе его можно поместить в любое место, которое потом затрется.
По поводу загрузки с диска. Сделать загрузку из ДОС очень просто и код будет даже меньше. Для остальных файловых систем все сведется к написанию соответствующих версий find_file/read_file. И какие проблемы в том, чтобы иметь разные версии загрузчика для разных файловых систем?
Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
Reddit
)