Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Aug 23, 2019 5:59 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 294 posts ]  Go to page Previous 113 14 15 16 1720 Next
Author Message
PostPosted: Mon Sep 27, 2010 4:58 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
VaStaNi
VaStaNi wrote:
вывешивать надо!
Вот пример "вывешивания". Обратите внимание на количество человек, принявших участие в обсуждении очень конкретного вопроса и глубину проработки поставленной проблемы.


Top
   
 Post subject: отзывы 1
PostPosted: Mon Sep 27, 2010 5:18 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
От модератора: Речь в этом посте идет о проекте микроядра, но поскольку обсуждение отошло от темы, то некоторые посты перемещены в эту тему.

----------------------------------------------------------------------------------------

Почитал. На самом деле сколько-нибудь полноценным проектом это не является даже близко, и работать по такому документу нельзя (впрочем, автор и не утверждает обратного).

Как должно вестись проектирование системы? Попробую кратко изложить своё видение этого вопроса.

1. Очерчивается круг задач, для которых будет предназначена система -- как ближайший, так и в достаточно отдалённой перспективе.

2. Очерчивается аппаратная база, для которой она предназначается.

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

3. Определяется, какие системные сервисы предоставляются прикладному программисту. Например, могут ли две задачи совместно пользоваться одной и той же областью памяти? Частный случай предыдущего: могут ли они совместно использовать одну и ту же копию динамически загружаемой библиотеки? Как выдаются права на доступ и как (с точки зрения прикладника, подчёркиваю это) они контролируются? Каким образом между задачами поддерживаются отношения "родитель-потомок"? Каким образом задачи выполняют операции ввода-вывода? Ну и т.д. и т.п.

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

4. Выбирается архитектура системы (микроядро или монолитно-модульная конструкция, причём ещё надо определиться с терминологией, а то некоторые к микроядерным и Винду относят).

5. Вырабатываются принципы связи между различными компонентами системы, механизмы низкоуровневой синхронизации, разруливания прерываний и т.п.

6. Проектируются крупные "строительные блоки" системы -- менеджер памяти, менеджер ввода-вывода и т.д.

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

7. И только теперь можно начать реализацию проекта.

Конечно, на каждом этапе возможно (а на п. 7 и неизбежно) возникновение ситуаций, когда что-то оказывается неясным или неподходящим. Тогда надо возвращаться назад и выполнять дополнительное проектирование (если что-то пропустили) или даже перепроектирование (если что-то оказалось в итоге спроектированным неправильно).


Top
   
PostPosted: Mon Sep 27, 2010 6:38 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Serge

Увы, таких примеров очень много.
Но есть и другие примеры:
viewtopic.php?f=1&t=662
(можно спорить насколько важен оказался результат в данном частном случае, но все-таки это был настоящий коллективный мозговой штурм)

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

Поверь, в твоих чрезмерно лаконичных и отрывочных тезисах очень сложно разобраться, надо лезть в код.
А на это не у всех есть время и желание. К тому же у многих - ярко выраженная идиоСИнкразия.


Top
   
PostPosted: Mon Sep 27, 2010 7:12 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Вот по такому плану пишутся GNU Hurd или Duke Nukem Forever.
Собрались мужики, посовещались, составили подробный проект и сели писать код. И пока писали ВНЕЗАПНО появились PCI, SMP, ACPI, USB, HotPlug, виртуализация. И прект встал. А остальным приходится работать методом последовательных приближений. Когда Торвальдс выложил первые исходники там и обработчиков исключений нормальных не было. И ничего, постепенно появилось всё. Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.


Top
   
PostPosted: Mon Sep 27, 2010 7:14 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
SII
Поправочка к примеру из п.2

Простая встраиваемая система (мы здесь говорим об операционной системе, так?) часто требуется чтобы выжать "из железа" максимум производительности (пример - управление крылатой ракетой автономное идентификационное устройство с корреляционным распознаванием образов). Поддержка многопроцессорности здесь очень даже не помешает.
Так что фразами типа
Quote:
там это не нужно и, что самое важное, никогда не будет нужно --
я бы не бросался.


Top
   
PostPosted: Mon Sep 27, 2010 7:18 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

О каких модулях идёт речь?

Насчёт документации согласен, расписывать всё долго и подробно ненавижу.


Top
   
PostPosted: Mon Sep 27, 2010 7:29 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Serge
Не соглашусь. Если разработчики упомянутых проектов не в состоянии довести их до ума -- так это их проблемы. Если появление перечисленных Вами аппаратных прибамбасов развалило их проект -- значит, он был недостаточно гибким (ну или они просто поленились переработать в достаточной степени).

art_zh
Я не даром написал "простая". Распознавание образов -- вряд ли простая система (во всяком случае, я её к таковым не отношу: это не опрос 20 термодатчиков и 30 манометров с последующей отправкой обработанной инфы по сети на дисплюй главного технолога). Кроме того, Вы прекрасно понимаете, что таких систем -- мизер по сравнению с общим количеством, а поэтому целью может быть создание ОС, подходящей для основной массы применений, но не годящейся для какой-то ограниченной части (из серии "овчинка не стоит выделки" -- трудозатраты велики и не окупятся возможной прибылью, например). Ну и, наконец, этот пример -- не более, чем просто иллстрация мысли о том, что надо сначала определиться в целью, а потом уж проектировать и тем более реализовывать, а не сначала что-то слепить, а потом пытаться его к чему-нибудь приспособить.


Top
   
PostPosted: Mon Sep 27, 2010 8:38 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Serge

devman, ddk, atikms и др. - каким компилятором пользоваться и какие библиотеки подключать, чтоб не сильно париться?

На http://kolibrios.org/load.cgi?f/releases/kolibri_0.7.7.0_sdk.7z всякой всячины полно, а как и с чем работать - до сих пор не въехал :oops:


Top
   
PostPosted: Mon Sep 27, 2010 9:52 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
SII wrote:
Я не даром написал "простая". Распознавание образов -- вряд ли простая система...
А я не даром подчеркнул "операционная".
Даже совершенно примитивная ОС вполне может обеспечивать решение чудовищно сложных практических задач. Опрос 20 датчиков или полноценное техническое зрение - это уже заботы конкретного приложения.

SII wrote:
Кроме того, Вы прекрасно понимаете, что таких систем -- мизер по сравнению с общим количеством, а поэтому целью может быть создание ОС, подходящей для основной массы применений, но не годящейся для какой-то ограниченной части (из серии "овчинка не стоит выделки" -- трудозатраты велики и не окупятся возможной прибылью, например).

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

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

Да, надо определиться с целью. Хорошенько обдумать многие принципиальные вопросы, включая 6 перечисленных Вами.

И прежде чем браться за нечто совершенно новое - прикинуть, не разумнее ли будет попытаться довести до ума то, что кто-то уже худо-бедно слепил?


Top
   
PostPosted: Tue Sep 28, 2010 3:09 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
(с) бред - удалено автором


Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.

Top
   
PostPosted: Tue Sep 28, 2010 3:25 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
(с) бред - удалено автором


Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.

Top
   
PostPosted: Tue Sep 28, 2010 4:18 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
(с) бред - удалено автором


Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.

Top
   
PostPosted: Tue Sep 28, 2010 10:16 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
(с) бред - удалено автором


Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.

Top
   
PostPosted: Tue Sep 28, 2010 11:35 pm 
Чувствую опять все закончится тем, что большинство уйдет на полгода в астрал... до следующей "течки".


Top
   
 Post subject: отзывы 3
PostPosted: Wed Sep 29, 2010 12:05 am 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Ну, я в разработке КОС никаким боком-раком не участвую, но в случае чего (т.е. нормального проектирования с нуля без попыток сохранения совместимости на уровне ядра и т.п.) сие возможно, а поэтому на всякий случай опишу свою кочку зрения.

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

Средства реализации: ассемблер для модулей ядра, ассемблер или надёжный язык (на практике -- Паскаль и/или Ада, поскольку сколько-нибудь вменяемую реализацию Модулы или Оберона найти проблематично, да и известны народу они куда хуже Паскаля) для кода пользовательского режима и, возможно, части кода ядра (во всяком случае, пока идёт написание и отладка логики; впоследствии можно и переписать вручную на ассемблер, если это будет сочтено полезным). Категорически не приемлю Си/Си++: это лишь источник трудноуловимых глюков, а читабельности по сравнению с асмом почти не добавляет (а при неумеренном использовании возможностей сваливать всю в одну кучу -- даже уменьшает).

Требования к системе: обязательная поддержка 64-разрядных процессоров, многопроцессорности, PnP, ACPI, в близкой перспективе -- UEFI... В общем, всего того, что необходимо для полноценной десктопной системы. В то же время считаю, что система должна строиться так, чтобы она могла работать и в качестве ОСРВ (в первом приближении это сводится к тому, что время её реакции на прерывания должно быть предсказуемым: для любого заранее известного набора оборудования должна иметься возможность точно посчитать наихудшее возможное время от поступления запроса на прерывание от конкретного устройства до начала выполнения первой команды обработчика этого прерывания).

Замечу также, что в моём "плане" (который озвучил где-то в другом месте) даже выбор архитектуры, не говоря уже о средствах реализации, выполняется весьма и весьма поздно: для одного и того же АПИ можно написать и монолитную систему, и микроядерную -- приложениям это абсолютно пофиг.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 294 posts ]  Go to page Previous 113 14 15 16 1720 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited