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

Kernel architecture questions
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:00 pm, edited 1 time in total.
  • Чем рисовал ?

    Принципиально не отличается от того, что сейчас есть в Колибри.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:00 pm, edited 1 time in total.
  • 10 тем более 100 кГц на PC это горячка и тупое расходование тактов на обслуживание прерываний.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
  • VaStaNi wrote:Я бы на ЖРВ хорошо замахнулся и в принципе так оно и есть, но есть мега проблема призвезденый SMM в SMI в бивисе, на котором отчасти и стоит ваш любимый в последнее время ACPI (посты так и блещут фразами, что типа оседладь бы надо, кстати никто вразумительно не написал накой он ему нужен).
    Отвечу, на кой этот самый ACPI нужен. Без него невозможно _стандартным_ (а значит, гарантированно работоспособным образом) узнать про наличие ряда устройств материнской платы. Без него невозможно _стандартным_ образом настраивать некоторые устройства, управлять их состояниями и т.п. В частности, невозможно оптимизировать энергопотребление системы, например, переводить часть процессоров в режим сна, если для них нет работы.

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

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

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

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

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


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

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

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

    Я рискую возразить: не обязательно. Для себя я имею право склепать такую систему, которая мне больше подходит.
    И на которую я ухлопаю меньше времени, сил и средств.
    Естественно, имеете полное право. Просто Ваша система не будет работать на другой платформе, что для меня (и многих других) неприемлемо. Но, как уже говорил, это определяется самой постановкой задачи, поэтому мы с Вами не непримеримые враги, а просто идущие по разным дорогам в разные конечные пункты :)
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
  • VaStaNi
    Не обижайся, я вовсе не собирался тебя чем-то зацепить.
    Ты обращался лично ко мне? -- я изложил свое мнение.
    Действительно, с точки зрения инженера некоторые сложнейшие RTOS-проблемы можно более эффективно решить схемотехнически.

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

    _____
    P.S. У каждого участника проекта - не только своя точка зрения, но и свои стимулы для работы.
    Не все работают ради развлечения или самообразования.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:01 pm, edited 1 time in total.
  • В качестве рекламной паузы могу сказать, что Mario и SII были правы - с понедельника я работаю в одном из пиар агентств Новосибирска, куда меня взяли в мои 16 лет. Самое интересное, что работа вообще не связана с компьютерами и IT. Они мой проект по корпоративным играм практически купили и заодно взяли меня как реализатора в свое новое подразделение. Так что программирование теперь точно только хобби.
  • Ну, все будешь теперь как-бы CEOшником. :mrgreen:
  • Ну как бы как ... З/п мне нравится)
  • Who is online

    Users browsing this forum: No registered users and 7 guests