Всем доброго времени суток!
Некоторые могли видеть, что около месяца назад я создал на 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 год назад "Трудно переходить на нормальную коллективную разработку после стольких лет раздолбайства, возможно не все понимают, что это намного лучше, чем писать очередной свой велосипед, в тайне от всех, и так и не завершать начатое, однако я надеюсь на лучшее." (мне в интервью). Это единственный путь.
Новая ветка ядра
-
- Attachments
-
-
mike.dld.doc (37 KiB)
- Упомянутое интервью с Майком. К сожалению, у нас тогда не хватило времени и я успел задать только половину вопросов.
Downloaded 730 times
-
Чо за К++? Если ЯВУ, то втопку! А так, я за.
Ну мне если честно больше интересно мнение ядерщиков, нежели пользователей в данном вопросе)
Посмотрели уже 50 человек.
Идеи то такого характера высказывали и до меня, неужели именно тот факт, что именно _я_ её высказал вызывает равнодушие?
Посмотрели уже 50 человек.
Идеи то такого характера высказывали и до меня, неужели именно тот факт, что именно _я_ её высказал вызывает равнодушие?
maximYCH
Ты здесь не причём. Тема регулярно поднимается, перерастает в знатный флуд и на этом благополучно умирает. Ты мыслишь в правильном направлении, начинать надо с проектирования и обсуждения, но если хочешь сдвинуть воз с мётвой точки придётся долго и упорно тянуть его самому. Иначе все превратится в вот это и особенно в вот это
Для затравки определись для чего тебе нужно ядро: десктоп, сервер, реальное время/встроенные применения ?
Ты здесь не причём. Тема регулярно поднимается, перерастает в знатный флуд и на этом благополучно умирает. Ты мыслишь в правильном направлении, начинать надо с проектирования и обсуждения, но если хочешь сдвинуть воз с мётвой точки придётся долго и упорно тянуть его самому. Иначе все превратится в вот это и особенно в вот это
Для затравки определись для чего тебе нужно ядро: десктоп, сервер, реальное время/встроенные применения ?
Согласен. А чтобы это действительно стало реально, операционная система должна быть как конструктор - модульной. Модульной либо статически на уровне исходников, как в Linux, либо динамически как в Qnx. Так как нет ни того, ни другого, то остаётся,Для затравки определись для чего тебе нужно ядро: десктоп, сервер, реальное время/встроенные применения ?
Короче, все кому не безразлична KolibriOS изучаем системное программирование. Я не исключениеесли хочешь сдвинуть воз с мёртвой точки придётся долго и упорно тянуть его самому
![Smile :)](./images/smilies/icon_smile.gif)
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
А мне нужен монолит.
Двухдюймовыми болтами прикрученный к конкретной аппаратной платформе, без браузеров, Ю-тюба и офисов.
И то, что я нашел в сегодняшней Колибри, мне по-настоящему нравится.
Надо просто последовательно доводить до ума то, что уже есть.
Двухдюймовыми болтами прикрученный к конкретной аппаратной платформе, без браузеров, Ю-тюба и офисов.
И то, что я нашел в сегодняшней Колибри, мне по-настоящему нравится.
Надо просто последовательно доводить до ума то, что уже есть.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Как все радужно, воздушные замки в чистом небе, подсвеченном восходящим солнцем...
Так, а теперь проза:
На уровне хобби проекта развитие очень медленное, так как мало ресурсов. Как коммерческая система тоже не тянет - нет спроса. Можно конечно сто раз написать как все можно сделать замечательно и почему до этого это все не было сделано, но по сути ничего не меняется. Эффект Linux нам не повторить. По этой причине я лично вижу только путь коммерческого развития. Давайте честно признаемся сами себе - что выделять даже 30 минут в сутки в среднем получается пока есть энтузиазм, а он как показывает практика достаточно быстро заканчивается. Как это не прискорбно начинать надо с разработки бизнес-модели и не просто:
Возможно стоит отказаться от упора исключительно на ассемблер (я наступаю себе на горло - но против правды далеко не попрешь), но не ломиться по пути *nix - у системы свой, пусть тернистый, путь и некоторые вещи можно реализовать лучше. POSIX не панацея. Переносимость возможно, но не обязательно. Упор имеет смысл делать в основном на x86-64. При этом не бросая текущую систему. Кому интересно могут продолжать.
Я к сожалению не имею экономического образования, чтобы предложить обоснованный бизнес-план, а вообще такие вещи обычно обсуждают в приватной обстановке, ибо конкуренция для нас страшная вещь.
Вот в общем все. С таким посылом я лично буду готов работать. Выражаю исключительно свое мнение, без всяких имхов написанных крупными буквами.
Так, а теперь проза:
На уровне хобби проекта развитие очень медленное, так как мало ресурсов. Как коммерческая система тоже не тянет - нет спроса. Можно конечно сто раз написать как все можно сделать замечательно и почему до этого это все не было сделано, но по сути ничего не меняется. Эффект Linux нам не повторить. По этой причине я лично вижу только путь коммерческого развития. Давайте честно признаемся сами себе - что выделять даже 30 минут в сутки в среднем получается пока есть энтузиазм, а он как показывает практика достаточно быстро заканчивается. Как это не прискорбно начинать надо с разработки бизнес-модели и не просто:
А конкретно продумывая чего можно достичь малыми силами за разумные сроки.Serge wrote:десктоп, сервер, реальное время/встроенные применения
Возможно стоит отказаться от упора исключительно на ассемблер (я наступаю себе на горло - но против правды далеко не попрешь), но не ломиться по пути *nix - у системы свой, пусть тернистый, путь и некоторые вещи можно реализовать лучше. POSIX не панацея. Переносимость возможно, но не обязательно. Упор имеет смысл делать в основном на x86-64. При этом не бросая текущую систему. Кому интересно могут продолжать.
Я к сожалению не имею экономического образования, чтобы предложить обоснованный бизнес-план, а вообще такие вещи обычно обсуждают в приватной обстановке, ибо конкуренция для нас страшная вещь.
Вот в общем все. С таким посылом я лично буду готов работать. Выражаю исключительно свое мнение, без всяких имхов написанных крупными буквами.
Mario
Малыми силами можно написать микроядро без "обвеса".
Малыми силами можно написать микроядро без "обвеса".
Интересная вещь. Размышляя над тем, как вообще организовать работу с графикой и окнами в текущем ядре KolibriOS, я пришёл к выводу, что его надо поделить на модули с определённым интерфейсом. Но возникли вопросы какие модули должны быть в ring 0, а какие в ring 3, и какой должен быть интерфейс, чтобы 100 раз его не переделывать . И тут напрашивались идеи гибридных систем и микроядер.....
P.S.
Нашёл в сети интересную книжку "Кёртен. Введение в QNX-Neutrino2. Руководство по программированию в QNX.Realtime." Формат djvu. Объясняются принципы устройства QNX.
Я тоже об этом думал. Микроядро на чистом ассемблере. А "обвес" хочешь на 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!
Kolibri is best operation system in the world!
Некоторые книги по QNX.
http://filesurf.ru/162998/book2.pdf.html
http://filesurf.ru/162999/QNX.djvu.html
http://filesurf.ru/163000
http://filesurf.ru/162998/book2.pdf.html
http://filesurf.ru/162999/QNX.djvu.html
http://filesurf.ru/163000
andrew_programmer
На ассемблере выйдут те же яйца, только в профиль. Он нужен только для очень специализированных вещей - точек входа ядра и обработчиков прерывания. Всё остальное неплохо получается и на С. Например так
Иногда даже очень неплохо
На ассемблере выйдут те же яйца, только в профиль. Он нужен только для очень специализированных вещей - точек входа ядра и обработчиков прерывания. Всё остальное неплохо получается и на С. Например так
![Very Happy :D](./images/smilies/icon_biggrin.gif)
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 ассемблер, либо чисто ассемблерный код).
Я имел ввиду разработку при условии, что не все люди знают 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!
Kolibri is best operation system in the world!
И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?". Прямо по Кэрроллу -"Надо очень быстро бежать вперед, чтобы оставаться на месте"...
Хорошо будем ковыряться дальше в песочнице.
Хорошо будем ковыряться дальше в песочнице.
Можно по подробнее. Я не совсем понял о чём конкретно речь.И все таки закрыли глаза на главный недостаток. Я конечно понимаю что обсуждать "Как?" куда приятней чем "Зачем?".
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Первый пост - никакого тайного смысла. Я все подробно писал. Если нравится смотреть через розовое стекло на жизнь, тогда пожалуйста - можно продолжать в том же русле с тем же результатом.
З.Ы. Пока что все это сходно с игрой в линейку, где персы 80 уровня лупят персов 70 уровня реально прожигая свою жизнь, но ничего не получая взамен в реальной жизни.
З.Ы. Пока что все это сходно с игрой в линейку, где персы 80 уровня лупят персов 70 уровня реально прожигая свою жизнь, но ничего не получая взамен в реальной жизни.
Who is online
Users browsing this forum: No registered users and 11 guests