Board.KolibriOS.org

Отвечу по тем пунктам где я виноват, что они вообще появились. Наверное мне не нужно было вообще делать, так как я делаю 90% говна.

Не обязательно. Можно выделять динамически, добавляя по мере обнаружения новых разделов. Хочется? Вперед.

Размер выбран с запасом под максимальный режим экрана. Вроде 2400*1600, точно не помню. Можно выделять динамически, выбирая под текущий размер видеорежима. Хочется? Вперед.

Это не мое, но влезу - потому что я такой говнюк, который таки лезет везде. А еще я один из самых старых маразматиков в проекте.

Перезапуск ядра без перезапуска компьютера был полезной фичей в некоторых случаях. Например для смены разрешения экрана - это быстрее чем добавлять BIOS и рестарт железа.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

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

Serge
Ревизия 3558 поломала изменения сделанные в ревизии 3536. Теперь меню снова срабатывает через раз.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

А теперь ?

Ревизия 3576 исправила проблему. Спасибо.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Многострадальное ядро kolibri-process готово к тестам.
Хотя Колибри поддерживает многопоточность, потоки одного процесса фактически независимы друг от друга. Каждый поток хранит свой набор данных, в том числе и разделяемых между потоками одного процесса. Это создаёт проблемы при изменении таких данных,например при операциях с памятью или загрузках DLL, потому что необходимо найти и модифицировать содержимое в структурах других потоков. Синхронизация доступа к данным так же проблематична. Kolibri-process решает эту проблему при помощи новой структуры PROC, хранящей общие переменные.

struct  PROC
        list            LHEAD
        thr_list        LHEAD
        heap_lock       MUTEX
        heap_base       rd 1
        heap_top        rd 1
        mem_used        rd 1
        dlls_list_ptr   rd 1
        pdt_0_phys      rd 1
        pdt_1_phys      rd 1
        io_map_0        rd 1
        io_map_1        rd 1

        unused          rb 4096-$; reserved for handles
        pdt_0           rd 1024
ends

Каждая структура хранит указатели двусвязного списка дочерних потоков, мьютекс кучи приложения, указатель списка загруженных dll, физические адреса страничного каталога и карты разрешения ввода-вывода. В структуру APPDATA добавлены указатели двусвязного списка потоков и указатель на структуру родительского процесса. В результате изменений в ядре удалось упростить код, уменьшить его размер и ускорить некоторые системные вызовы.

Serge
А уже существующий код использующий многопоточность сильно переделывать придется при переходе на ядро kolibri-process?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Mario_r4
Для приложений пока ничего не меняется. Потом добавлю мьютексы и другие примитивы для синхронизации.

Зачем io_map делать per-process, а не per-thread?

_________________
Сделаем мир лучше!

Оставлять per-thread как-то не логично. Это же часть адресного пространства, значит должна быть общей для всех потоков в процессе.

Порты ввода-вывода - часть адресного пространства?

_________________
Сделаем мир лучше!

На мой взгляд да, параллельная часть. Если поток получит доступ к mmio, его получат и остальные потоки в адресном пространстве. Почему с традиционными портами должно быть иначе ?

Как-то лениво народ реагирует. Ладно, лучший тест - ночная сборка. Через пару дней залью.

Serge, спасибо. Вроде бы работает всё стабильно. Дымовой тест точно проходит

_________________
Через тернии к звездам

Да, карта ввода-вывода - это составная часть адресного пространства процесса, и к потокам не имеет никакого отношения.