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

Kernel architecture questions
  • Чем рисовал ?

    Принципиально не отличается от того, что сейчас есть в Колибри.
  • (с) бред - удалено автором
    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:
  • Ну как бы как ... З/п мне нравится)
  • К слову, ребят, обратите внимание на новые телеки, которые не так давно появились. Это, например LED седьмой серии от Сименса (SAMSUNG LED TV Series 7). Они построены на комбинации различных девайсов под управлением специальной сборки Линукса. Вообще, вся домашняя техника интегрируется и связывается медийными протоколами, например, DLNA. Так вот, в телеках нет интерфейса как такового, вместо этого просто броузер, который поддерживает скрипты. DSP процессор декодирует сигнал и выводит его в конкретное место на экране телевизора, а реализовано это как плагин к броузеру. Не нужен никакой риалтайм ;) всё быстрое можно сделать в специальных девайсах, как тут было правильно отмечено выше (контроллеры, ЦПОС, их комбинации, ПЛИС и т.д.).

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

    Ну так вот, к чему я клоню. Если вы тут разрабатываете такую низкоуровневую софтину, то её вполне можно было бы применять в будущих домашних интерактивных девайсах. Через лет 5 все телики будут подключены к инету или иметь такую возможность. Так очередь может дойти и до других девайсов - стиральных машин и пылесосов ;) только не смейтесь, стиральные машины уже... но вот засовывать комп туда не удобно, а вот если бы была программно-аппаратная платформа для моделирования умного дома, да ещё и открытая (ну или полуоткрытая), то можно было бы занять нишу.

    Что касается промышленного применения, то я думаю, что вряд ли вы тут можете конкурировать с такими монстрами как Siemens и его промышленными контроллерами или с мин обороны США и бывшей ракетной ОС RTEMS, которую в частности сейчас применяет Infinet wireless в своих средствах связи нового поколения.

    Но вот средства автоматизации, куда ещё не дошли руки у корпораций, вполне могут быть по силам. Умная домашняя автоматика пока слабо представлена, а промышленные образцы мягко говоря не отвечают десктопным стандартам красивости, если кто видел когда-нить HMI на пультах промышленных предприятий. Промышленные контроллеры слишком дороги для домашних целей.

    Думайте быстрее :) некоторые товарищи считают, что ось должна быть вот такой:
    http://www.dz.ru/solutions/phantom
    http://vkontakte.ru/video-11538465_132540619
  • Who is online

    Users browsing this forum: No registered users and 7 guests