В Haiku улучшается поддержка своппинга

Благодаря Google Summer of Code студент Жао Шуай успешно завершил свой проект: в Haiku теперь есть поддержка своппинга. Она включена с 27233 сборки, и используя своп, файл можно удвоить доступую RAM. Размер своп файла может меняться (или выключаться) через панель настроек VirtualMemory.

Поддержка своппинга позволит наконец собирать Haiku из под Haiku на машинах с менее 800 MB RAM при наличии места в свопе. Я испробовал это на Core 2 Duo 2.2 GHz с 256 MB RAM (искусственно уменьшенной) и 1.5 GB своп файлом. Сборка стандартного образа Haiku с двумя джемами (jam -j2) заняла около 34 минут. Не очень-то и быстро, но Haiku пока не вполне оптимизирована.

Реализациая своппинга в Haiku в огромной степени позаимствована из FreeBSD. Не настолько совершенной, но Жао собирается сделать больше FreeBSD-шных оптимизаций.

Ingo Weinhold

Чем помочь с m68k

По мере того, как порт для m68k начинает вырисовываться, возможно, кто-то из вас захочет протянуть мне руку помощи, поэтому я расскажу как установить рабочую среду. После того, как я объясню, почему я выбрал эту платформу, мы займёмся системой сборки и эмулятором для отладки выбранной платформы.

Почему бы не Мак? Я хочу это для моей Amiga! Готов отдать свой NeXT!

(Не отказался бы ;))

Выбор целевой платформы обусловлен наличием имеющихся эмуляторов m68k-машин. В QEMU есть режим m68k, но это все лишь ColdFire. Ни одна из существующих машин не эмулируется.

Большинство операционных систем той эры поддерживают CPU с 68000 по 68030. Это значит, что на самом деле MMU для 030 и выше не используется. Большинство машин используют дешёвые версии, вроде 68EC030, который плох и как FPU, и как MMU. Это справедливо для большинства Амиг, для которых, разумеется можно поставить процессорную плату с 040 или 060. Но для Haiku требуется mmu. У меня есть Mac LC III, в котором полноценный 030, однако Basilisk II не эмулирует MMU, насколько я знаю, поскольку раз на большинстве маков его нет, он и не используется, кроме как для свопинга в некоторых версиях.

Я не знаю ни одного эмулятора Next, если знаете - напишите.

Продолжение

Модифицируем отладчик ядра

В отличие от BeOS наше ядро содержит куски кода на C++, которые иногда причиняют кучу головной боли, года смотришь стек отладчиком ядра, потому что символы искалечены линковкой бинарников так, что надо использовать Decode__12CrypticCNamesPCc. Помню, видел private API для gcc4 по расшифровке символов в читаемые имена, но код, делавший это, из libsupc++, был написан без учёта реалий Kernel Debugging Land, и использовал вызовы malloc, realloc и free... Я всё ещё очень хотел видеть нормальные имена и не сдавался. Я также хотел иметь возможность получать ассемблерные дампы, потому что не у всех есть последовательный кабель для работы с внешним отладчиком.

статья полностью

Работа над ядром для 68k

Когда-нибудь я должен написать о начале работы над портом для 68k, есть о чём рассказать...
Сегодня^Wвечером^Wутром эээ, хм, хорошо, сейчас я попытаюсь сделать живой репортаж о том, на чём остановился в прошлый раз: как сделать, чтобы ядро грузилось корректно.

продолжение