А мне нужен монолит.
Двухдюймовыми болтами прикрученный к конкретной аппаратной платформе, без браузеров, Ю-тюба и офисов.
И то, что я нашел в сегодняшней Колибри, мне по-настоящему нравится.
Надо просто последовательно доводить до ума то, что уже есть.
Новая ветка ядра
-
Евангелие от Иоанна: стих 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
На ассемблере выйдут те же яйца, только в профиль. Он нужен только для очень специализированных вещей - точек входа ядра и обработчиков прерывания. Всё остальное неплохо получается и на С. Например так
Иногда даже очень неплохо
На ассемблере выйдут те же яйца, только в профиль. Он нужен только для очень специализированных вещей - точек входа ядра и обработчиков прерывания. Всё остальное неплохо получается и на С. Например так
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 уровня реально прожигая свою жизнь, но ничего не получая взамен в реальной жизни.
Mario и вообщем то все:
Давайте примем за ответ на вопрос "Зачем?" следующее:
"Разработка KolibriOS ведется для личного самообразования, однако самообразование подразумевает собой в данном случае не только навыки программирования на языках и алгоритмах, но и получение навыков работы в команде и работы на продукт. При этом нельзя исключать возможность, что с появлением тех или иных наработок для данной системы, ориентация может свернуть в другое русло, к примеру, серверное или десктопное". Это означает, что для отдельных людей этот проект пишется для самообразования, однако каждый, кто участвует в разработке несет некоторую долю ответственности за свое поведение в проекте, за код и его качество, которое он внес и т.д. Естественно, по факту ответственности нет - однако, если человек матерится на IRC или пишет некачественный наразборчивый код и орет "А чего это тут не так?", то естественно, такого отношения быть не должно. Должны быть какие-то рамки. Ведь этот проект, считайте, пишется _действительно_ для самообучения - ну тогда извольте и учиться жить в программерском коллективе.
Относительно встроенного ядра. Собственно, я не вижу в этом проблемы. Текущее ядро человека, который этим занимается, устраивает. Что мешает ему самому над ним дальше работать, учитывая, что только ему это и интересно и все остальные думают в противоположном направлении (микроядро)? В branches и все. Тем более, что до окончания проектировки я чувствую, ой как много (к той же OS/2 проектировочной документации 700 листов). Понятно, что мы может ограничимся и меньшим объемом, но это важная работа.
Mario, пойми - как ты выразился, путь Linux нам не повторить. Путь Windows тем более. Во встроенных и без нас есть, ну а среди нас и так есть, кто занимается этими вопросами. Я больше не вижу коммерческих путей развития.
Давайте примем за ответ на вопрос "Зачем?" следующее:
"Разработка 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 то самообразование т.е. инвестиции в себя очень хороший вариант.
AT&T действительно ужасен. .intel_syntax помогает, но иногда с ним возникали сложности при компиляции.
Если под "Зачем?" подразумевается PROFIT то самообразование т.е. инвестиции в себя очень хороший вариант.
Вообщем-то. Обсуждение, которое не относится к самой проектировке, по-моему:
1. Разрядность кода.
Так или иначе, но постепенно 32 битные процессоры уходят с арены. Это уже сейчас заметно, и это не прихоть - это уже почти веление времени. И дело не только в том, что сама по себе технология лучше, интереснее, и т.д. 32 битный режим, как можно помнить позволяет адресовать до 4 Гб памяти (с помощью PAE расширяется до 64 ГБ - там физический адрес 36 бит вместо 32, но ценой приличных извратов). А учитывая темпы развития техники (не ПО, а техники), этого мало.
2. Проектирование.
Ну, во первых, у меня есть мысль, что начинать проектирование нужно с API, только в широком смысле -- не просто описать набор функций, а описать достаточно подробно, что они делают, как связаны между собой и т.п. В частности, надо расписать управление памятью и процессами (как процессы могут разделять память друг с другом и т.п.). Это позволит сформировать четкую систему ввода/вывода. Кроме того, есть предложение - реализовывать это все на псевдоязыке или Pascal/Ada изначально, а только потом переносить на ассемблер. Для того, что бы отловить глюки логики работы, алгоритмов, неправильной проектировки.
Кроме того, я не знаю, насчет формата проектирования и обсуждения - подойдет ли для этих целей форум? Потому что, если да - куда это все запихнуть, если учесть, что микротемы теряются в ходе обсуждения? Выделять для каждой микротемы (Зачем, разрядность и т.д.) свою тему?
3. Прочие вопросы - инструменты, лицензии, и т.д.
Ну это потом уже.
А также, о проектах и вообще кстати Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
1. Разрядность кода.
Так или иначе, но постепенно 32 битные процессоры уходят с арены. Это уже сейчас заметно, и это не прихоть - это уже почти веление времени. И дело не только в том, что сама по себе технология лучше, интереснее, и т.д. 32 битный режим, как можно помнить позволяет адресовать до 4 Гб памяти (с помощью PAE расширяется до 64 ГБ - там физический адрес 36 бит вместо 32, но ценой приличных извратов). А учитывая темпы развития техники (не ПО, а техники), этого мало.
2. Проектирование.
Ну, во первых, у меня есть мысль, что начинать проектирование нужно с API, только в широком смысле -- не просто описать набор функций, а описать достаточно подробно, что они делают, как связаны между собой и т.п. В частности, надо расписать управление памятью и процессами (как процессы могут разделять память друг с другом и т.п.). Это позволит сформировать четкую систему ввода/вывода. Кроме того, есть предложение - реализовывать это все на псевдоязыке или Pascal/Ada изначально, а только потом переносить на ассемблер. Для того, что бы отловить глюки логики работы, алгоритмов, неправильной проектировки.
Кроме того, я не знаю, насчет формата проектирования и обсуждения - подойдет ли для этих целей форум? Потому что, если да - куда это все запихнуть, если учесть, что микротемы теряются в ходе обсуждения? Выделять для каждой микротемы (Зачем, разрядность и т.д.) свою тему?
3. Прочие вопросы - инструменты, лицензии, и т.д.
Ну это потом уже.
А также, о проектах и вообще кстати Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
maximYCH
tsdima
Serge
Про AT&T - это наверное все-таки к Андрею?
З.Ы. Ребята вы можете сколько угодно проектировать и писать код, но поезд далеко не уедет пока не будут определена целевая ниша. Ладно походу я опять без всякой пользы ввязываюсь в малополезную (по крайней мере для меня ) дискуссию. Делайте как знаете, но я в таком проекте участвовать не буду.
Мне вот интересно - это как гадание на кофейной гуще?При этом нельзя исключать возможность, что с появлением тех или иных наработок для данной системы, ориентация может свернуть в другое русло, к примеру, серверное или десктопное".
От людей можно что-либо требовать лишь поставив их в зависимость - например ЗП, наличие определенных привилегий, можно еще к затылку приставить пистолет, т.е. угрозой расправы, других способов человечество не придумало.однако каждый, кто участвует в разработке несет некоторую долю ответственности за свое поведение в проекте, за код и его качество, которое он внес и т.д. Естественно, по факту ответственности нет - однако, если человек матерится на 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