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

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

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

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

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

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

    Малыми силами можно написать микроядро без "обвеса".
  • Интересная вещь. Размышляя над тем, как вообще организовать работу с графикой и окнами в текущем ядре 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.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer

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

    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 
  • Serge
    Я имел ввиду разработку при условии, что не все люди знают C. Некоторых от C, а уж тем более от AT&T синтаксиса встроенного ассемблера вообще выворачивает наизнанку. Я тоже долго не мог разобраться во встроенном ассемблере AT&T синтаксиса. После Intel синтаксиса - это кажется вообще верхом извращенства над ассемблером. Но потом привык.
    Ещё на ассемблере можно писать некоторые драйверы. Если нравиться человеку ассемблер, так пусть пишет не нём. Мне и самому ассемблер очень нравиться, только когда дело касается соотношения
    СКОРОСТЬ_РАЗРАБОТКИ=(ОБЪЁМ РАБОТЫ)/(ВРЕМЯ ВЫПОЛНЕНИЯ РАБОТЫ)
    я логику пишу на C, а скоростные участки кода на ассемблере(либо встроенный inline ассемблер, либо чисто ассемблерный код).
    Last edited by andrew_programmer on Tue Jan 26, 2010 2:12 pm, edited 1 time in total.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?". Прямо по Кэрроллу -"Надо очень быстро бежать вперед, чтобы оставаться на месте"...
    Хорошо будем ковыряться дальше в песочнице.
  • И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?".
    Можно по подробнее. Я не совсем понял о чём конкретно речь.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Первый пост - никакого тайного смысла. Я все подробно писал. Если нравится смотреть через розовое стекло на жизнь, тогда пожалуйста - можно продолжать в том же русле с тем же результатом.

    З.Ы. Пока что все это сходно с игрой в линейку, где персы 80 уровня лупят персов 70 уровня реально прожигая свою жизнь, но ничего не получая взамен в реальной жизни.
  • Mario и вообщем то все:
    Давайте примем за ответ на вопрос "Зачем?" следующее:
    "Разработка KolibriOS ведется для личного самообразования, однако самообразование подразумевает собой в данном случае не только навыки программирования на языках и алгоритмах, но и получение навыков работы в команде и работы на продукт. При этом нельзя исключать возможность, что с появлением тех или иных наработок для данной системы, ориентация может свернуть в другое русло, к примеру, серверное или десктопное". Это означает, что для отдельных людей этот проект пишется для самообразования, однако каждый, кто участвует в разработке несет некоторую долю ответственности за свое поведение в проекте, за код и его качество, которое он внес и т.д. Естественно, по факту ответственности нет - однако, если человек матерится на IRC или пишет некачественный наразборчивый код и орет "А чего это тут не так?", то естественно, такого отношения быть не должно. Должны быть какие-то рамки. Ведь этот проект, считайте, пишется _действительно_ для самообучения - ну тогда извольте и учиться жить в программерском коллективе.
    Относительно встроенного ядра. Собственно, я не вижу в этом проблемы. Текущее ядро человека, который этим занимается, устраивает. Что мешает ему самому над ним дальше работать, учитывая, что только ему это и интересно и все остальные думают в противоположном направлении (микроядро)? В branches и все. Тем более, что до окончания проектировки я чувствую, ой как много (к той же OS/2 проектировочной документации 700 листов). Понятно, что мы может ограничимся и меньшим объемом, но это важная работа.
    Mario, пойми - как ты выразился, путь Linux нам не повторить. Путь Windows тем более. Во встроенных и без нас есть, ну а среди нас и так есть, кто занимается этими вопросами. Я больше не вижу коммерческих путей развития.
    Last edited by maximYCH on Tue Jan 26, 2010 3:49 pm, edited 1 time in total.
  • Мне кажется, что Колибри ОС - это прежде всего открытый проект. А фразы "открытый проект" и "получая взамен в реальной жизни", на мой взгляд, несколько не совместимы.

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

    Но от участия в проекте нового ядра/ОС я бы не отказался.
  • Mario

    AT&T действительно ужасен. .intel_syntax помогает, но иногда с ним возникали сложности при компиляции.

    Если под "Зачем?" подразумевается PROFIT то самообразование т.е. инвестиции в себя очень хороший вариант.
  • Вообщем-то. Обсуждение, которое не относится к самой проектировке, по-моему:
    1. Разрядность кода.
    Так или иначе, но постепенно 32 битные процессоры уходят с арены. Это уже сейчас заметно, и это не прихоть - это уже почти веление времени. И дело не только в том, что сама по себе технология лучше, интереснее, и т.д. 32 битный режим, как можно помнить позволяет адресовать до 4 Гб памяти (с помощью PAE расширяется до 64 ГБ - там физический адрес 36 бит вместо 32, но ценой приличных извратов). А учитывая темпы развития техники (не ПО, а техники), этого мало.
    2. Проектирование.
    Ну, во первых, у меня есть мысль, что начинать проектирование нужно с API, только в широком смысле -- не просто описать набор функций, а описать достаточно подробно, что они делают, как связаны между собой и т.п. В частности, надо расписать управление памятью и процессами (как процессы могут разделять память друг с другом и т.п.). Это позволит сформировать четкую систему ввода/вывода. Кроме того, есть предложение - реализовывать это все на псевдоязыке или Pascal/Ada изначально, а только потом переносить на ассемблер. Для того, что бы отловить глюки логики работы, алгоритмов, неправильной проектировки.
    Кроме того, я не знаю, насчет формата проектирования и обсуждения - подойдет ли для этих целей форум? Потому что, если да - куда это все запихнуть, если учесть, что микротемы теряются в ходе обсуждения? Выделять для каждой микротемы (Зачем, разрядность и т.д.) свою тему?
    3. Прочие вопросы - инструменты, лицензии, и т.д.
    Ну это потом уже.

    А также, о проектах и вообще кстати Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
  • maximYCH
    При этом нельзя исключать возможность, что с появлением тех или иных наработок для данной системы, ориентация может свернуть в другое русло, к примеру, серверное или десктопное".
    Мне вот интересно - это как гадание на кофейной гуще?
    однако каждый, кто участвует в разработке несет некоторую долю ответственности за свое поведение в проекте, за код и его качество, которое он внес и т.д. Естественно, по факту ответственности нет - однако, если человек матерится на IRC или пишет некачественный наразборчивый код и орет "А чего это тут не так?", то естественно, такого отношения быть не должно. Должны быть какие-то рамки. Ведь этот проект, считайте, пишется _действительно_ для самообучения - ну тогда извольте и учиться жить в программерском коллективе.
    От людей можно что-либо требовать лишь поставив их в зависимость - например ЗП, наличие определенных привилегий, можно еще к затылку приставить пистолет, т.е. угрозой расправы, других способов человечество не придумало.

    tsdima
    А фразы "открытый проект" и "получая взамен в реальной жизни", на мой взгляд, несколько не совместимы.
    Здрасте! А все объяснения что free вообще то свобода, а не бесплатно - в топку?
    Не скрою, мысли о написании ОС с нуля на основе имеющейся в исходниках информации посещала и меня, но я ясно себе представляю, что в одиночку я с этим не справлюсь.
    Каждый из нас ярый индивидуалист и нет цементирующих факторов. Цементирующим фактором была-бы коммерческая выгода, но при таком подходе (полное отрицание), конечно все будет бесполезным.

    Serge
    Про AT&T - это наверное все-таки к Андрею?
    PROFIT то самообразование т.е. инвестиции в себя очень хороший вариант.
    Я все это понимаю, но участие в проекте обеспечивает только базовый уровень. Итого имеем человек придя в проект немного поковырявшись получил базовый уровень, устроился на работу - а там с него требуют этот базовый уровень и плюсом нечто совершенно отличающееся, в результате человек уже проектом не занимается. И так повторяется много, много, много раз. Дальше в проекте остаются в лучшем случае единицы - нету стимула продолжать работу. При наличии поддержки люди могли бы заниматься исключительно проектом и с них можно было бы что-либо спрашивать. Не было бы ситуации когда человек работает, что-то ломает, а потом сматывает удочки и через полгода все начинают орать что не работает. Епть - ответственность хоть какая-то была бы. А так как был бардак, так и останется.

    З.Ы. Ребята вы можете сколько угодно проектировать и писать код, но поезд далеко не уедет пока не будут определена целевая ниша. Ладно походу я опять без всякой пользы ввязываюсь в малополезную (по крайней мере для меня ) дискуссию. Делайте как знаете, но я в таком проекте участвовать не буду.
    Last edited by Mario on Tue Jan 26, 2010 4:11 pm, edited 1 time in total.
  • Who is online

    Users browsing this forum: No registered users and 1 guest