Page 18 of 20

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

Posted: Sun Oct 03, 2010 5:00 pm
by Serge
Phantom-84

Переходи сюда. Требуется разработать архитектуру и API под уже существующую систему.

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

Posted: Fri Oct 08, 2010 12:47 pm
by VaStaNi
(с) бред - удалено автором

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

Posted: Fri Oct 08, 2010 1:18 pm
by Serge
Чем рисовал ?

Принципиально не отличается от того, что сейчас есть в Колибри.

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

Posted: Fri Oct 08, 2010 3:37 pm
by VaStaNi
(с) бред - удалено автором

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

Posted: Fri Oct 08, 2010 5:03 pm
by Serge
10 тем более 100 кГц на PC это горячка и тупое расходование тактов на обслуживание прерываний.

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

Posted: Fri Oct 08, 2010 8:20 pm
by VaStaNi
(с) бред - удалено автором

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

Posted: Fri Oct 08, 2010 10:44 pm
by SII
VaStaNi wrote:Я бы на ЖРВ хорошо замахнулся и в принципе так оно и есть, но есть мега проблема призвезденый SMM в SMI в бивисе, на котором отчасти и стоит ваш любимый в последнее время ACPI (посты так и блещут фразами, что типа оседладь бы надо, кстати никто вразумительно не написал накой он ему нужен).
Отвечу, на кой этот самый ACPI нужен. Без него невозможно _стандартным_ (а значит, гарантированно работоспособным образом) узнать про наличие ряда устройств материнской платы. Без него невозможно _стандартным_ образом настраивать некоторые устройства, управлять их состояниями и т.п. В частности, невозможно оптимизировать энергопотребление системы, например, переводить часть процессоров в режим сна, если для них нет работы.

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

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

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

Posted: Sat Oct 09, 2010 12:32 am
by art_zh
VaStaNi
На диаграмме оно конечно понятней. Еще лучше (совсем идеально) было бы хотя бы некоторые цифирки пояснять текстом.
Основная идея понятна, но имхо чрезмерно наворочена, по крайней мере если сравнивать с примитивным таскменеджером Колибри.

Хочу высказать одну крамольную вещь: я, как инженер-электронщик, осознаю важность RTOS-концепций, но меня воротит от чрезмерно зарегулированной и всёгарантирующей системной опеки ЖРВ.

Если я сомневаюсь в реактивности (или синхронности) ОС, я просто впихиваю критичную по времени функцию в железо (впаиваю подходящий FIFO-буфер или планирую более умный контроль внешнего устройства на ПЛИСах), а компьютеру оставляю компьтерово - сбор и анализ данных.
Чтобы управлять датчиками и релюхами - RTOS не нужен. Нужны ЛАшки, триггера, буферные регистры, текстолит и хлорное железо.

Совсем другая задача: RT-оптимизация ядра - она действительно нужна, но к ЖРВ-системе отношения не имеет.


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

Стоит ли гальванизировать монстра ради управления вентиляторами и батарейками, если того же можно в добиться в 100 байт, напрямую?
Вы аргументированно отвечаете: да. Многие в этом с Вами согласятся.

Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
И на которую я ухлопаю меньше времени, сил и средств.

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

Posted: Sat Oct 09, 2010 12:52 am
by SII
art_zh wrote:Чтобы управлять датчиками и релюхами - RTOS не нужен. Нужны ЛАшки, триггера, буферные регистры, текстолит и хлорное железо.
Естественно, всё задачей определяется.
ACPI избавляет от необходимости знать всё о конкретном железе на конкретной платформе
Но справедлива и антитеза: для хорошо документированной платформы можно собрать полноценную и компактную ОС, избавленную от (большинства) ACPI-заморочек.
Абсолютно с Вами согласен. Если исходить из Вашей постановки задачи (ОС узкого применения, заточенная под конкретную хорошо документированную платформу), именно Ваш подход мне представляется оптимальным. Просто у меня ориентир совершенно другой: любой достаточно современный ПК, а тут обойтись без вещей, подобных ACPI, уже нереально (мало того, что железо разнообразно, так оно зачастую и не документировано: попробуй, например, найди спецификации, необходимые для управления питанием процессора на матерях Gigabyte с их технологией DES).
Стоит ли гальванизировать монстра ради управления вентиляторами и батарейками, если того же можно в добиться в 100 байт, напрямую?
Вы аргументированно отвечаете: да. Многие в этом с Вами согласятся.

Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
И на которую я ухлопаю меньше времени, сил и средств.
Естественно, имеете полное право. Просто Ваша система не будет работать на другой платформе, что для меня (и многих других) неприемлемо. Но, как уже говорил, это определяется самой постановкой задачи, поэтому мы с Вами не непримеримые враги, а просто идущие по разным дорогам в разные конечные пункты :)

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

Posted: Sun Oct 10, 2010 11:06 am
by VaStaNi
(с) бред - удалено автором

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

Posted: Sun Oct 10, 2010 12:54 pm
by art_zh
VaStaNi
Не обижайся, я вовсе не собирался тебя чем-то зацепить.
Ты обращался лично ко мне? -- я изложил свое мнение.
Действительно, с точки зрения инженера некоторые сложнейшие RTOS-проблемы можно более эффективно решить схемотехнически.

Да, в каждом конкретном случае надо будет разводить новую схему.
Но ведь и программист под каждую частную задачу должен разрабатывать особый код, так?
В большинстве случаев решения диктуются соображениями экономической целесообразности и реальными сроками заказа.

_____
P.S. У каждого участника проекта - не только своя точка зрения, но и свои стимулы для работы.
Не все работают ради развлечения или самообразования.

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

Posted: Mon Oct 11, 2010 6:53 pm
by VaStaNi
(с) бред - удалено автором

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

Posted: Wed Nov 03, 2010 9:32 pm
by maximYCH
В качестве рекламной паузы могу сказать, что Mario и SII были правы - с понедельника я работаю в одном из пиар агентств Новосибирска, куда меня взяли в мои 16 лет. Самое интересное, что работа вообще не связана с компьютерами и IT. Они мой проект по корпоративным играм практически купили и заодно взяли меня как реализатора в свое новое подразделение. Так что программирование теперь точно только хобби.

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

Posted: Wed Nov 03, 2010 10:45 pm
by Mario
Ну, все будешь теперь как-бы CEOшником. :mrgreen:

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

Posted: Thu Nov 04, 2010 7:51 am
by maximYCH
Ну как бы как ... З/п мне нравится)