Последнее время разработка ядра XSystem замедлилась ввиду банальной нехватки времени у лидера проекта — SadKo (то есть, меня).

Тем не менее, разработка продолжается, но ввиду кардинальных переделок время нового релиза проекта продолжает отодвигаться.

Помимо этого, для дальнейшего успешного развития проекта требуется своевременное документирование функций ядра.

Именно поэтому проекту сейчас особенно требуются новые участники:

• разработчики С/С++/Assembler;
• технические писатели.

Напомним, что, проект развивается без какого-либо финансирования, на чистом энтузиазме его участников. Тем не менее, если проект Вам интересен и Вы хотите поучаствовать в нём, милости просим.

Как-никак, а развитие ядра потихоньку идёт.
В последнее время мною был реализован загрузчик PE-файлов в память с последующим запуском в user level. Реализация загрузчика PE немножко замедлила реализацию загрузчика файлов формата ELF, так как я обнаружил серьёзные изъяны в функциях, работающих с файлами. Нужно будет переписывать их реализацию. А так, надеюсь, к сентябрю успею выпустить новый релиз.

Стал внезапным участником переезда. Смена 24 квадратных метров жилища на 17 (UPD: 15) — это полная жп…
Простите те, кому что-то в ближайшее время обещал. Скорее всего, не выполню обещания в срок.
Особенно прошу прощения у klark973 , так как, скорее всего, так и не успею написать скрипт к отъезду.

А сейчас пока я большей частью в офлайн. И http://xskernel.org/ тоже временно не пашет.

Всё-таки нашёл в себе силы реализовать менеджер виртуальной памяти в XSystem. Конечно, готов он не на все 100%, но бОльшая часть уже действительно оттестирована и работает. Как подтверждение этого ядро было переведено на новый менеджер, а старый был выкинут из дерева проекта.
Теперь ядро умеет одинаково хорошо обращаться с обычной страничной адресацией и PAE (Page-Address Extension). Для этого достаточно перекомпилировать ядро с соответствующими параметрами.
В ближайшее время на wiki постараюсь разместить документацию по сделанному менеджеру. Зато сейчас как гора с плеч: пришлось очень долго и очень много думать, как правильнее реализовать менеджер. Теперь же можно потихоньку начинать разделять user-space и kernel-space для процессов.
Механизм подкачки пока не реализован, но это уже — отдельный разговор.

Задумался о кросс-компиляции моего ядрышка GCC (сейчас пока компилируется только Watcom’ом).

Первый большой и краеугольный камень — это, конечно, ассемблерные вставки. Поэтому был придуман механизм, чтобы минимизировать писанину и дублирование ассемблерного кода для обоих компиляторов. С этой целью я сделал некий заголовочный файл, в котором объявил:

#ifdef __WATCOMC__
    // Define Pragmas
    #define inline_func(prag_d, ret_t, body)    ret_t __pragma(#prag_d) body;
    #define inline_proc(prag_d, body)           void  __pragma(#prag_d) body;
#endif /* __WATCOMC__ */

#ifdef __GNUC__
    // Define Pragmas
    #define inline_func(prag_d, ret_t, body)        \
        static __inline ret_t body                  \
        {                                           \
            ret_t __result;                         \
            __asm__ __volatile__ (                  \
                    ".intel_syntax noprefix"        \
                    prag_d                          \
            );                                      \
            return __result;                        \
        }

    #define inline_proc(prag_d, body)               \
        static __inline void body                   \
        {                                           \
            __asm__ __volatile__ (                  \
                    ".intel_syntax noprefix"        \
                    prag_d                          \
            );                                      \
        }
#endif /* __GNUC__ */

Заметим, что для GNU GCC я заведомо врубил синтаксис интела (ну не люблю я синтаксис AT&T, да и нафиг он не нужен на i386, на мой взгляд).

Теперь, допустим, захотел я сделать функцию __strlen на ассемблере. Для этого я ворочу соответствующие макросы:

#define __I386_STREND_IMPL          \
        "mov    ecx, -1"            \
        "xor    al, al"             \
        "repne  scasb"

// macro for strlen() function
#define __I386_STRLEN               \
        __I386_STREND_IMPL          \
        "mov    eax, -2"            \
        "sub    eax, ecx"

И связываю эти макросы с параметрами для каждого компилятора по-своему:

#if defined(__WATCOMC__)
    // strlen function bindings for Watcom
    #pragma aux I386_STRLEN     =       \
            __I386_STRLEN               \
            parm caller [edi]           \
            value [eax]                 \
            modify [edi ecx]
#elif defined(__GNUC__)
    // strlen function bindings for GCC
    #define I386_STRLEN                 \
            __I386_STRLEN               \
            : "=a"(__result)            \
            : "D"(str)
#endif /* compiler detection */

После чего осталось объявить прототип функции:

inline_func(I386_STRLEN,    size_t,     __strlen(const char *str)                       )

Всё, теперь я могу использовать функцию __strlen, и она будет инлайниться во всех участках кода как для GCC, так и для Watcom. Замечательно, не правда ли?

Несмотря на то, что репозиторий ОС XSystem мигрировал ко мне на домашний сервер, всё же хорошо было бы хранить бэкапы на каком-нибудь удалённом сервере.
Для этого я решил воспользоваться уже имеющимся репозиторием subversion на http://sourceforge.net/.

Идея работы такая: раз в сутки мой репозиторий должен синхронизироваться с удалённым репозиторием. При этом, все изменения в одном репозитории должны однозначно отражаться на другом. С версии subversion 1.4 появилась такая тулза, как svnsync, но она для моего случая не подходит: оба репозитория не предоставляют прямого доступа к svnroot.

#!/usr/bin/perl

use strict;

my @blacklist   =
(
    qr(^\.svn|\/\.svn$),
    qr(^\.{1,2}$|\/\.{1,2}$)
);

my $src_path  = 'xsystem';
my $dst_path  = 'xskernel-sync';
my $svn_user  = '';
my $svn_pass  = '';

# Update repositories
`svn update $src_path`;
`svn update $dst_path`;

# now search files in src_path and compare to dst_path

add_files();
remove_files();

`svn commit $dst_path -m "Synchronization commit" --username $svn_user --password $svn_pass`;

sub md5sum
{
    my $fname = shift;
    if (open PIPE, "md5sum $fname |")
    {
        my $line =
;
        close PIPE;
        my ($sum) = ($line =~ /^(\w+)\s+/o);
        return $sum;
    }
    return undef;
}

sub ban_file
{
    my $src_file = shift;
    foreach (@blacklist)
    {
        ($src_file =~ $_) and
            return 1;
    }
    return undef;
}

sub add_files
{
    my @directories = ();
    my $curr_dir = '';

    do
    {
        # Открываем каталог
        if (opendir DIRHDL, "$src_path$curr_dir")
        {
            CYCLE: # Читаем содержимое каталога
            while (my $fname = readdir DIRHDL)
            {
                # Баним ненужные файлы
                my $src_file = "$src_path$curr_dir/$fname";
                (ban_file($src_file)) and
                    next CYCLE;

                my $dst_short = "$curr_dir/$fname";
                my $dst_file  = "$dst_path$dst_short";

                # Файл является каталогом?
                if (-d $src_file)
                {
                    # необходимо проверить, что он есть в destination-репозитории
                    unless (-d $dst_file)
                    {
                        # если каталога нет - его нужно создать
                        print "mkdir   $dst_short\n";
                        `mkdir -p $dst_file`;
                        `svn add $dst_file`;
                    }

                    # Запомним каталог для того, чтобы в будущем его просмотреть
                    push @directories, $dst_short;
                }
                else
                {
                    # проверяем, существует ли файл в destination-репозитории
                    unless (-e $dst_file)
                    {
                        # файл не существует, его нужно скопировать и добавить
                        print "add     $dst_short\n";
                        `cp -f $src_file $dst_file`;
                        `svn add $dst_file`;
                    }
                    else
                    {
                        # файл существует, вычисляем md5sum обоих файлов
                        my $sum1 = md5sum($src_file);
                        my $sum2 = md5sum($dst_file);

                        # если суммы не совпадают - заменяем файл новым
                        if ($sum1 ne $sum2)
                        {
                            print "replace $dst_short\n";
                            `cp -f $src_file $dst_file`;
                        }
                    }
                }
            }
        }
        else
        {
            print "Can't open dir $src_path$curr_dir\n";
        }

        # закрываем каталог и получаем следующий каталог, который следует обработать
        closedir DIRHDL;
        $curr_dir = shift @directories;
    }
    while (defined $curr_dir); # крутимся, пока в списке присутствуют обрабатываемые каталоги.
}

sub remove_files
{
    my @directories = ();
    my $curr_dir = '';

    do
    {
        # опять же, открываем каталог destination-репозитория
        if (opendir DIRHDL, "$dst_path$curr_dir")
        {
            CYCLE: # читаем файлы
            while (my $fname = readdir DIRHDL)
            {
                # баним недопустимые diren'ы
                my $src_file = "$dst_path$curr_dir/$fname";
                (ban_file($src_file))
                    and next CYCLE;

                my $src_short = "$curr_dir/$fname";
                my $dst_file  = "$src_path$src_short";

                # проверяем, является ли это каталогом
                if (-d $src_file)
                {
                    # проверяем, существует ли этот каталог в source-репозитории
                    unless (-d $dst_file)
                    {
                        # каталога нет - удаляем его из destination-репозитория
                        print "rmdir   $src_short\n";
                        `svn delete $src_file`;
                    }
                    else
                    {
                        # каталог существует, запоминаем его для дальнейшей обработки
                        push @directories, $src_short;
                    }
                }
                else
                {
                    # Это обычный файл, проверяем, есть ли он в source-репозитории
                    unless (-e $dst_file)
                    {
                        # Файла нет, удаляем его из destination-репозитория
                        print "unlink  $src_short\n";
                        `svn delete $src_file`;
                    }
                }
            }
        }
        else
        {
            print "Can't open dir $dst_path$curr_dir\n";
        }

        # Закрываем каталог, получаем следующий
        closedir DIRHDL;
        $curr_dir = shift @directories;
    }
    while (defined $curr_dir);
}

Недостаток этой тулзы один: если файл был перемещён, то он будет распознан как новый файл. Хотя, я не думаю, что файлы и каталоги так часто перемещаются в логически корректно построенном дереве проекта.

В связи с тем, что на форуме появился очень интересный баг:

http://forum.xskernel.org/viewtopic.php?f=10&t=18

Решил поиграться с виртуальными машинами, а именно проверить, как на них запускается XSystem.

Вот что из этого получилось:

В общем, APIC Timer дохнет по неизвестной причине в VirtualBox, что можно наблюдать на видео (в правом верхнем углу нет красных счётчиков как на остальных эмуляторах). Мало того, обычный ISA Timer работает очень медленно (обратите внимание на счётчик в левом верхнем углу).

Ну ISA Timer ещё можно простить, а вот APIC Timer почему дохнет — для меня загадка.
Создал баг на сайте virtual box:

http://www.virtualbox.org/ticket/2573

Выпущен новый релиз ОС XSystem — October 2008 Fishes: Carp.
Основные нововведения:
- Из дерева проекта удалены утилиты ‘xarch’ и ‘fontcut’.
- Полностью переписан планировщик (теперь более быстрый и надёжный).
- Блочный распределитель памяти теперь выделяет блоки с адресом, кратным 8 байтам.
- Исправлены ошибки в контроллере клавиатуры (теперь работает в Bochs).
- Оптимизации реализации библиотеки <string.h>.
- Частично перенесён код Watcom C++ Runtime Library, необходимый для использования C++ — конструкций.
- Изменены сборочные скрипты.
- Кодовые страницы перемещены в ‘media/share/codepages’.
- Изменён метод ‘for_file’ в утилите ‘xsmake’.
- Большинство архитектурно-зависимого кода вынесено в ветку ‘include/arch’ ядра.
- Написан прототип будущего механизма подкачки виртуальной памяти.
- Добавлена поддержка записи конфигурационного пространства шины PCI (экспериментальное).
- Реализована поддержка загрузки/сохранения контекстов FPU/MMX/SSE при переключении задач.
- Добавлена защита от ошибочного прерывания со стороны PIC.
- Доступна загрузка с USB Flash Drive.
- Первичный загрузчик (‘bootload’) полностью переписан для поддержки файловых систем FAT12 и FAT16.
- Вторичный загрузчик ‘xload’ переписан на C++.
- Добавлены функции ‘unlink’, ‘cp’ в утилите ‘xsmake’.
- Добавлена условная конструкция ‘if-else’ в утилиту ‘xsmake’.
- Добавлена проверка зависимостей в OMF-файлах утилитой ‘xsmake’.
- Переписана утилита ‘rawmake’ (поддержка создания образов FAT12 и FAT16-дисков).
- Утилиты ‘xsmake’, ‘exe2bin’ и ‘rawmake’ теперь также можно собрать с помощью GNU GCC под Linux.

Вот и дожили до того, что открыл форум своего проекта.
Расположен он здесь: http://forum.xskernel.org/
Если есть желание реально поучаствовать в проекте и/или обсудить его — приветствую гостей.
Основной сайт тут: http://xskernel.org/ .
А здесь можно найти кое-какую полезную документацию: http://wiki.xskernel.org/ .

Уже где-то вторую или третью неделю непроизвольно соблюдаю правило «ни дня без коммита».

Хм… К чему бы это? Наверное, к новому релизу…

Написал статейку на WIKI про планировщик потоков:

http://wiki.xskernel.org/doku.php/xskernel/ipc/scheduler

Новый планировщик пофиксил много неприятных багов и корявостей в ядре. И (о чудо!), казалось бы, для более сложной реализации планировщика новая версия работает на порядок быстрее старой.