Board.KolibriOS.org

Posted: **Sat Jan 23, 2010 8:53 pm**

Всем доброго времени суток!
Некоторые могли видеть, что около месяца назад я создал на Wiki страницу http://wiki.kolibrios.org/Open_message. Итак, у меня накопились мысли и появилось время, которое необходимо, что юы мысли привести в порядок и изложить.
(Пометка: убедительная просьба - читать ниже написанное не как КОМАНДУ или ПРИКАЗ, а как ВОПРОС К ОБСУЖДЕНИЮ. Я никогда не старался и не хотел быть главнокомандующим).
Diamond уже писал о том, что если сейчас составлять документацию на устройство системы (ядра в частности), то в очень многих моментах придется написать о том, что "реализовано вот так-то, хотя понятно что должно быть вот-так, но пока работает". Это очень важный момент. Поддержка LBA48, SMP, Plug&Play, ACPI, APIC (как следствие - USB, SATA и много чего ещё) упирается именно в не расширяемость ядра, в то, что ОЧЕНЬ многое написано "кривовато", о чем писал diamond. А причинах этих кривоватостей в том, что ядро не было СПРОЕКТИРОВАНО. Операционная система - очень сложный технический проект, который с бухты барахты, как его пытались последние 10 лет писать не пишется. И поверьте. Сейчас в ядре ~30 000 кода. Но. Это мертвый код. Кое-что вышеуказанное к нему добавить если и можно, то ТАКИМИ бредовыми костылями, что похлеще тех, что есть сейчас. Если сейчас ввести PnP, то придется переписывать всю модель ввода/вывода. А без этого - развитие мертво. Да, можно сделать PnP, USB, SATA без полной переписки. Но это будут большие громоздкие неудобные костыли. А без этого всего дальше можно только писать приложения, м.б. переписать часть GUI. И все. И дальше тупик. И лучше переписать сейчас, когда у нас пока реально хорошо работают только десяток приложений по 10 Кб.
В конце концов, даже если сделать PnP костылем, то прийдется переписывать работу с моделью ввода/вывода и устройствами. Сейчас появился kord. Он заменит в какой то момент загрузчик. Для GUI нужно вынести графику из ядра. Аналогично с сетью. Казалось бы, ядро тогда будет в порядке, т.к. основное переписали. НЕ БУДЕТ. Старый код будет глючить в связке с новым, и будет куча проблем.
Вообщем.
Я хотел бы поставить вопрос о реализации нового ядра.
А теперь ещё одна ремарка. Что лично я могу сделать, дабы не быть голословным. Во первых, проектировка ядра (естественно, что не в виде талмудов на 700 страниц, но общие представления применимо к x86 страниц на 10-20, во вторых, К++, в третьих прикладное, в четвертых тестирование и документирование (что очень не мало важно - если не будет задокументирована работа, то работа считай почти даром).
Почему я до сих пор ничего не делал в прикладном ракурсе. Потому что СМЫСЛА делать под ОС с мертвым кодом приложения?
Предлагаю этапы:
1) Проектирование путем коллективного обсуждения (и что немало важно - сведение итогового документа, на основании которого собственно будет реализовываться ядро и подтверждение его всеми, кто будет принимать участие в его разработке (а я надеюсь что это будет интересно практически всем ядерщикам, кроме того, если представить такой документ на WASM, то вполне реально получить ещё парочку ядерщиков, если они будут понимать, что и как требуется на основании этого документа. Ещё можно перевести на английский (благо немного) и отправить на OSDev.org).
2) Реализация. Синхронная реализация, с обсуждением отдельных фрагментов кода, логики работы, методов оптимизации, совместного тестирования, консультирования. Как выразился mike.dld год назад "Трудно переходить на нормальную коллективную разработку после стольких лет раздолбайства, возможно не все понимают, что это намного лучше, чем писать очередной свой велосипед, в тайне от всех, и так и не завершать начатое, однако я надеюсь на лучшее." (мне в интервью). Это единственный путь.

Posted: **Mon Jan 25, 2010 6:45 pm**

Чо за К++? Если ЯВУ, то втопку! А так, я за.

Posted: **Mon Jan 25, 2010 7:39 pm**

Ну мне если честно больше интересно мнение ядерщиков, нежели пользователей в данном вопросе)
Посмотрели уже 50 человек.
Идеи то такого характера высказывали и до меня, неужели именно тот факт, что именно _я_ её высказал вызывает равнодушие?

Posted: **Mon Jan 25, 2010 8:48 pm**

maximYCH

Ты здесь не причём. Тема регулярно поднимается, перерастает в знатный флуд и на этом благополучно умирает. Ты мыслишь в правильном направлении, начинать надо с проектирования и обсуждения, но если хочешь сдвинуть воз с мётвой точки придётся долго и упорно тянуть его самому. Иначе все превратится в вот это и особенно в вот это

Для затравки определись для чего тебе нужно ядро: десктоп, сервер, реальное время/встроенные применения ?

Posted: **Mon Jan 25, 2010 11:21 pm**

Для затравки определись для чего тебе нужно ядро: десктоп, сервер, реальное время/встроенные применения ?

Согласен. А чтобы это действительно стало реально, операционная система должна быть как конструктор - модульной. Модульной либо статически на уровне исходников, как в Linux, либо динамически как в Qnx. Так как нет ни того, ни другого, то остаётся,

если хочешь сдвинуть воз с мёртвой точки придётся долго и упорно тянуть его самому

Короче, все кому не безразлична KolibriOS изучаем системное программирование. Я не исключение

Мануалы Intel/AMD в помощь.

Posted: **Tue Jan 26, 2010 12:01 am**

А мне нужен монолит.
Двухдюймовыми болтами прикрученный к конкретной аппаратной платформе, без браузеров, Ю-тюба и офисов.
И то, что я нашел в сегодняшней Колибри, мне по-настоящему нравится.
Надо просто последовательно доводить до ума то, что уже есть.

Posted: **Tue Jan 26, 2010 12:17 am**

Как все радужно, воздушные замки в чистом небе, подсвеченном восходящим солнцем...

Так, а теперь проза:
На уровне хобби проекта развитие очень медленное, так как мало ресурсов. Как коммерческая система тоже не тянет - нет спроса. Можно конечно сто раз написать как все можно сделать замечательно и почему до этого это все не было сделано, но по сути ничего не меняется. Эффект Linux нам не повторить. По этой причине я лично вижу только путь коммерческого развития. Давайте честно признаемся сами себе - что выделять даже 30 минут в сутки в среднем получается пока есть энтузиазм, а он как показывает практика достаточно быстро заканчивается. Как это не прискорбно начинать надо с разработки бизнес-модели и не просто:

Serge wrote:десктоп, сервер, реальное время/встроенные применения

А конкретно продумывая чего можно достичь малыми силами за разумные сроки.

Возможно стоит отказаться от упора исключительно на ассемблер (я наступаю себе на горло - но против правды далеко не попрешь), но не ломиться по пути *nix - у системы свой, пусть тернистый, путь и некоторые вещи можно реализовать лучше. POSIX не панацея. Переносимость возможно, но не обязательно. Упор имеет смысл делать в основном на x86-64. При этом не бросая текущую систему. Кому интересно могут продолжать.

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

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

Posted: **Tue Jan 26, 2010 1:01 am**

Mario

Малыми силами можно написать микроядро без "обвеса".

Posted: **Tue Jan 26, 2010 1:20 am**

Интересная вещь. Размышляя над тем, как вообще организовать работу с графикой и окнами в текущем ядре KolibriOS, я пришёл к выводу, что его надо поделить на модули с определённым интерфейсом. Но возникли вопросы какие модули должны быть в ring 0, а какие в ring 3, и какой должен быть интерфейс, чтобы 100 раз его не переделывать . И тут напрашивались идеи гибридных систем и микроядер.....

Малыми силами можно написать микроядро без "обвеса".

Я тоже об этом думал. Микроядро на чистом ассемблере. А "обвес" хочешь на C, не любишь C, так ассемблер. Это единственный способ снизить зависимость от: x86-32/SMP, x86-64/SMP. А иначе возьмут Intel и AMD, и придумают какую нибудь Asymmetric Multi Processors с кучей ядер, и придётся всё заново переделывать.

P.S.
Нашёл в сети интересную книжку "Кёртен. Введение в QNX-Neutrino2. Руководство по программированию в QNX.Realtime." Формат djvu. Объясняются принципы устройства QNX.

Posted: **Tue Jan 26, 2010 6:51 am**

Некоторые книги по QNX.
http://filesurf.ru/162998/book2.pdf.html
http://filesurf.ru/162999/QNX.djvu.html
http://filesurf.ru/163000

Posted: **Tue Jan 26, 2010 1:20 pm**

andrew_programmer

На ассемблере выйдут те же яйца, только в профиль. Он нужен только для очень специализированных вещей - точек входа ядра и обработчиков прерывания. Всё остальное неплохо получается и на С. Например так

Code: Select all

Немного модифицированный код из L4 
    __asm__ __volatile__(
    "lgdt %0          \n\t"
    "ljmp %1,$1f      \n\t "  /* refetch code segment descr.  */
    ".align 4         \n\t"
    "1:               \n"     /* by jumping across segments */
    :: "m"(gdt_desc), "i" (sel_os_code) );

    /* set the segment registers from the freshly installed GDT
       and load the Task Register with the TSS via the GDT */

    __asm__ __volatile__(
    "mov  %0, %%ds      \n\t" /* reload data segment      */
    "mov  %0, %%es      \n\t" /* need valid %es for movs/stos */
    "mov  %1, %%ss      \n\t" /* reload stack segment     */
    "mov  %2, %%gs      \n\t" /* load TLS segment         */
    "mov  %0, %%fs      \n\t" /* default                         */
    "xor %%eax, %%eax   \n\t" /*              */
    "lldt %%ax          \n\t" /* clear LDTR           */
    :
    : "r"(sel_app_data), "r"(sel_os_stack), "r"(sel_ostls)
    : "eax" );

    __asm__ __volatile__(
    "ltr %%ax \n\t"
    ::"a"(sel_tss));

Иногда даже очень неплохо

Code: Select all

static inline void outb(const uint16_t port, const uint8_t val)
{
    __asm__ __volatile__ ("outb %0, %w1" : : "a"(val), "dN"(port));
}

void init_pic()
{
    outb(0x20, 0x11);
    outb(0xA0, 0x11);

    outb(0x21, 0x20);
    outb(0xA1, 0x28);

    outb(0x21, 0x04);
    outb(0xA1, 0x02);

    outb(0x21, 0x01);
    outb(0xA1, 0x01);

    outb(0xA1, 0xFF);
    outb(0x21, 0xFF);
};

компилируется в 

                 public _init_pic
 _init_pic       proc near
                 mov     al, 11h
                 out     20h, al         ; Interrupt controller, 8259A.
                 out     0A0h, al        ; PIC 2  same as 0020 for PIC 1
                 mov     al, 20h ; ' '
                 out     21h, al         ; Interrupt controller, 8259A.
                 mov     al, 28h ; '('
                 out     0A1h, al        ; Interrupt Controller #2, 8259A
                 mov     al, 4
                 out     21h, al         ; Interrupt controller, 8259A.
                 mov     al, 2
                 out     0A1h, al        ; Interrupt Controller #2, 8259A
                 mov     al, 1
                 out     21h, al         ; Interrupt controller, 8259A.
                 out     0A1h, al        ; Interrupt Controller #2, 8259A
                 mov     al, 0FFh
                 out     0A1h, al        ; Interrupt Controller #2, 8259A
                 out     21h, al         ; Interrupt controller, 8259A.
                 retn
 _init_pic       endp

Posted: **Tue Jan 26, 2010 1:52 pm**

Serge
Я имел ввиду разработку при условии, что не все люди знают C. Некоторых от C, а уж тем более от AT&T синтаксиса встроенного ассемблера вообще выворачивает наизнанку. Я тоже долго не мог разобраться во встроенном ассемблере AT&T синтаксиса. После Intel синтаксиса - это кажется вообще верхом извращенства над ассемблером. Но потом привык.
Ещё на ассемблере можно писать некоторые драйверы. Если нравиться человеку ассемблер, так пусть пишет не нём. Мне и самому ассемблер очень нравиться, только когда дело касается соотношения
СКОРОСТЬ_РАЗРАБОТКИ=(ОБЪЁМ РАБОТЫ)/(ВРЕМЯ ВЫПОЛНЕНИЯ РАБОТЫ)
я логику пишу на C, а скоростные участки кода на ассемблере(либо встроенный inline ассемблер, либо чисто ассемблерный код).

Posted: **Tue Jan 26, 2010 2:00 pm**

И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?". Прямо по Кэрроллу -"Надо очень быстро бежать вперед, чтобы оставаться на месте"...
Хорошо будем ковыряться дальше в песочнице.

Posted: **Tue Jan 26, 2010 2:15 pm**

И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?".

Можно по подробнее. Я не совсем понял о чём конкретно речь.

Posted: **Tue Jan 26, 2010 2:27 pm**

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

З.Ы. Пока что все это сходно с игрой в линейку, где персы 80 уровня лупят персов 70 уровня реально прожигая свою жизнь, но ничего не получая взамен в реальной жизни.

Board.KolibriOS.org

Новая ветка ядра

Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра

Re: Новая ветка ядра