Обсуждение необходимости ACPI

Kernel architecture questions
  • А в больших все используют ACPI. У Майкрософт своя реализация, Эппл не знаю, а для остальных есть интеловская acpica. Все опенсорс оси делятся на те где есть acpica, и те где нет ACPI.
  • XVilka wrote:uniflash содержит куски кода, позаимствованные без спроса у flashrom http://www.flashrom.org/
    Я привел лишь для примера путь, как вариант, как люди ходят и успешно решают проблему(ы).
    "Содержит"? Ты хош сказать про нарушение лицензии? Дебаг и копипаст? Не в курсе. Знаю, что UniFlash лежал долго брошенным и "подотстал" одно время от железа, но потом вроде наши ребятки подсуетились и что то там подобавляли в основном впролне успешно вроде (работает).
    Serge wrote:VaStaNi
    Вместо одной acpi предлагается пять недо-acpi. Спасибо.
    НЕ недо-acpi, а что нибудь а-ля ACPI-KOS :D
    Я понял так, что ты категорически против нестандартных методов и своих технологий.
    Хотя надо признать, ведь цель рождает стредства, так? Тогда Цель должна оправдывать себя по сути по максимуму по эффективности.
    Нужно понимание зачем нужен собственно ACPI.
    Если чтобы на любой платформе выключать питание, то это много работы и мало эффекта с учетом массы недостатков и горбыльностей,
    а я вообще против SMI, как теневого и по сути паразитического механизма.
    Это раковая опухоль на размеренном пульсе сердца ОСи, хаотически пожирающая пачками кванты оси времени процессов.
    Это вообще "безсознательное состояние ОСи" помните, как у доцента джентльменов удачи: "тут все помню, а тут ничего не помню" и порой аж целых 5-10мс!
    Проц нихрена не знает, что с ним было и где собственно он был! Ах...еть! ВСЕ прерывания отложены и некоторые просрочены!!!
    Он (CPU) тупо не помнит, т.к. ему "дали по голове дубиной SMI" и он в ....!!! :mrgreen:
    Для современных процессоров 5-10мс - это капец 21 века!
    И 1мс "безсознанки CPU" - это тоже капец, если не гавном в ОСестроении заниматься.
    Сейчас не каменный век, чтобы закрывать глаза на такое, по крайней мере я так не могу.
    Имхо выводы.
    Быдлокод в обработчике SMI тому причина, а особенно "кодерские" конструкции ожиданий и временные выдержки для медленных девайсов XT машин (даже не AT) типа (упрощенно, но суть идиотизма сохранена):

    Code: Select all

       mov   ecx, xxxxx
    Wait_1:   .....
        .....
       ....
       loop  Wait_1
       in   al, dx
       and  al, nn
       out  dx, al
       mov   ecx, xxxxx
    Wait_2:   .....
        .....
       ....
       loop  Wait_2
       in   al, dx
    и это только для того чтобы, например, замерять напряжение на борту, КОТОРОЙ НИ ВЫ НИ ВАША ОСЬ (данные) НЕ ПОЛЬЗУЕТСЯ!?
    И собственно, не знает про них ничего!
    Или регульнуть кулер... вне Вашего желания (или ОСи)!
    И конечно рядом "припаян" ACPI, как типа развитие всего этого вороха, технологии APM... + еще всякого...
    Ну это поверхностно все вроде здорово, но ведь коряво все слеплено, жестоко и бездумно по отношению к ОСестроителям.
    Блин, какой нить абориген забабахал при помощи ECX+LOOP задержек, в совокупности на 5мс допустим, другой блин, тимлидер сраный, скомпилил проект BIOSa, его зашили в мою машину и продали. И теперь благодяря высокопривилигированному аппаратному событию SMI процессора с некоторым шагом по времени мой процессор улетает мозгом на каждые 5мс в никуда!!! Он просто выпадает из жизни, он просто пропадает отмораживается, как обкуренный. Ему нельзя доверять временные замеры в процессах, любых! Даже самых ядерных! Даже в пупер раскрученных RTOSх типа QNX!
    И на это закрывать глаза, успокаивать себя волшебным словом "стандарт"!? Нет, это для меня сугубый перебор, аборигеново решение, эти типа технологии и такой типа кодинг - нафиГ!
    Я против этой срани, во всяком случае пока все не изменится в гуманную сторону. Вот любопытно, как там в несколькими ядрами дела... Хоть бы кто нить расказал, исследовал и рассказал. Жаль времени нет...
    Serge wrote:Покажите плиз нумератор работающий на всех х86 платформах начиная с Pentium.
    Ну ты так и не сказал и похоже не описал (где читать?), что такое нумератор в твоем видении вообще? Нумератор всего и всех? Это перебор и нереальности. Где границы?
    Вот выше сказал конкретно так: "нумеровать ISA".
    Хорошо зацепка есть, есть граница, предел.
    Так вот то, что я привел с головой хватит. Проверял, смотрел.
    Сличал свои результаты по данному делу с тестовой программулиной ASTRA (рекомендую)
    Вот собственно типажные вещи, что может (должна) получать ОСь, как я считаю, при загрузке, вернее "развороте и оживанию ядра" (stage_1), еще никакие IDT, GDT не имеют права на жизнь...
    Тут ОСь еще только "готовится к господству" над всеми и вся, осматривает свои будующие владения, дабы юзать их правильно, рационально или просто знать, что это есть и учтено его наличие...
    Image
    Image
    Image
    вот и нумерация и ресурсы и параметры... не все?
    Наверное.
    Не так приведены?
    Ну и что, тансформируем в свое и потом пересечение методов даст полноту.
    Главное ЭТО УЖЕ ЕСТЬ! Его уже знает BIOS(знал BIOS при POST тестинге)
    Лишним инфа быть НЕ может, она может быть куцей, это да, но лучше чтото чем ничего! Факт и ИмХо! Хо Хо Хо! :)
  • Serge wrote:VaStaNi
    Вместо одной acpi предлагается пять недо-acpi. Спасибо.
    Покажите плиз нумератор работающий на всех х86 платформах начиная с Pentium.
    ISA? А надо?
  • Serge wrote:А в больших все используют ACPI. У Майкрософт своя реализация, Эппл не знаю, а для остальных есть интеловская acpica. Все опенсорс оси делятся на те где есть acpica, и те где нет ACPI.
    Для энумерации устройств и раскидывания прерываний - да, используют. А вот дальше...
    А дальше для чего-то им нужны драйвера, в т.ч и для чипсетов ("Обнаружено новое устройство. Вставьте диск...").
    А кое-кому даже и PM-драйвера ("Только у нас! Новинка сезона! Установи PowerNOW! и больше не перегревайся...") :lol:

    теперь 2 вопроса на засыпку:
    1) если у нас есть свои драйвера чипсета, то на кой этот ACPI вообще сдался?
    2) если у нас нет драйверов чипсета, то нафиг нам ACPI? (ах, да - прерывания и шатдаун, это конечно крутизна... и вообще - почти как у взрослых)
    VaStaNi wrote:а я вообще против SMI, как теневого и по сути паразитического механизма.
    Это раковая опухоль на размеренном пульсе сердца ОСи, хаотически пожирающая пачками кванты оси времени процессов. (в цитатник)
    Это вообще "безсознательное состояние ОСи" помните, как у доцента джентльменов удачи: "тут все помню, а тут ничего не помню" и порой аж целых 5-10мс!
    А это чтобы никто таких штучек не насобачился делать.
    Из подручных материалов. Если Когда прижмет.
  • art_zh
    Ну если всё так с дровами замечательно то нафига тогда в Майкрософт эту ACPI придумали ? И не на пустом месте ведь возникла. Прямая наследница разных PnP ISA и даже PnP коды устройств знает. Меня не особо интересует управление питанием, заряд батареи, подсветка экрана, мониторинг температуры и прочие фичи доступные через acpi. А вот определение устройств с ресурсами интересует очень. И в этом ACPI представляется мне единственным универсальным средством.
    Spoiler:PIC
    IO range 020-021
    IO range 0a0-0a1
    IRQ 2

    DMAD
    DMA channel 4
    IO range 00-0f
    IO range 081-083
    IO range 087-087
    IO range 089-08b
    IO range 08f-08f
    IO range 0c0-0df

    TMR
    IO range 040-043
    IRQ 0

    RTC0
    IO range 070-071
    IRQ 8

    SPKR
    IO range 061-061

    COPR
    IO range 0f0-0ff
    IRQ 13

    FDC
    IO range 03f0-03f5
    IO range 03f7-03f7
    IRQ 6
    DMA channel 2

    HPET
    Memory range 0fed00000-0fed003ff

    OMSC
    Memory range 0fec00000-0fec00fff
    Memory range 0fee00000-0fee00fff

    RMSC
    IO range 010-01f
    IO range 022-03f
    IO range 062-063
    IO range 065-06f
    IO range 072-07f
    IO range 080-080
    IO range 084-086
    IO range 088-088
    IO range 08c-08e
    IO range 090-09f
    IO range 0a2-0bf
    IO range 0b1-0b1
    IO range 0e0-0ef
    IO range 04d0-04d1
    IO range 040b-040b
    IO range 04d6-04d6
    IO range 0c00-0c01
    IO range 0c14-0c14
    IO range 0c50-0c51
    IO range 0c52-0c52
    IO range 0c6c-0c6c
    IO range 0c6f-0c6f
    IO range 0cd0-0cd1
    IO range 0cd2-0cd3
    IO range 0cd4-0cd5
    IO range 0cd6-0cd7
    IO range 0cd8-0cdf
    IO range 0800-089f
    IO range 00-0ffffffff
    IO range 0b00-0b0f
    IO range 0b20-0b3f
    IO range 0900-090f
    IO range 0910-091f
    IO range 0fe00-0fefe
    Memory range 0ffb80000-0ffbfffff
    Memory range 0fec10000-0fec1001f

    PS2K
    IO range 060-060
    IO range 064-064
    IRQ 1

    UAR1
    IO range 03f8-03ff
    IRQ 4
    Вот в логе сразу видно какие устройства ISA есть на материнской плате, какие порты используются. Это только небольшая часть доступной информации. Адреса apic, число процессоров, роутинг прерываний, всё видно через ACPI.
    Есть на замену универсальное решение ?

    И в защиту SMI.
    SMI это мышки и клавы. Вы уже драйвер для EHCI+RMH написали ? Тогда не спешите хаять SMI.
  • А тут имеет место быть "конфликт интересов". art_zh занимается встраиваемыми системами, которые должны работать в реальном времени -- а с такими задачами ACPI совмещается, так скажем, плохо (разве что для начального поиска устройств, да и то под вопросом, ведь надо гарантировать, что никакого гадского кода SMM после инициализации системы выполняться точно не будет, иначе о реальном времени можно забыть). Кроме того, в таких задачах, вообще говоря, набор оборудования известен заранее, и именно под него создаётся (ну или "дорабатывается напильником") ОС; соответственно, нет нужды что-то там в процессе начальной загрузки определять.

    Но задачи, которые ставит перед собой (и перед ОС) art_zh -- исключение, а не правило. Основную массу людей, использующих ПК, ОСРВ не интересуют, им нужны десктопные системы (недаром все три самых распространённых на ПК именно такие -- Винда, Линух и МакОС). А вот в этом случае без ACPI, какой бы гадостью он не был, вообще обойтись нельзя, поскольку: а) нет иного универсального способа обнаружения всех устройств, расположенных на материнке; б) нет иного универсального способа управлять энергопотреблением, вентиляторами и прочими фишками из этой области. Да, и без всего этого система может быть вполне работоспособной и пригодной для решения широкого круга задач, однако её конкурентоспособность во многих случаях будет сомнительна даже в чисто техническом плане (про доступность прикладного ПО и драйверов в данном случае речи нет, разговор только о системе как таковой), особенно в перспективе. То же касается SMP, нормального PnP "на все случаи жизни" и т.д.

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

    Кстати, об унификации. Что МеОС (а значит, и выросшая оттуда КОС) представляет из себя полный бардак, мне стало ясно без того, чтобы смотреть на исходники, достаточно было увидеть список системных функций. В одну кучу свалено всё подряд, никакой системы нет, на новый тип устройств надо изобретать новые системные вызовы... Похоже, этот самый Вилле идеальным подходом к созданию АПИ для ОС считал путь, принятый в БИОС, где, как известно, имеется миллион функций, добавленных когда попало и кем попало, причём обычно без малейших попыток задуматься о будущем хотя бы на ближайшие 5 лет. Конечно, изнутри весь этот хаос можно реализовать очень эффективно, но в итоге всё равно получится хаос -- только оптимизированный.
  • art_zh wrote:1) если у нас есть свои драйвера чипсета, то на кой этот ACPI вообще сдался?
    Даже если бы не дрова, а только путные доки!
    Вот поэтому эти сссссукииииии жмут ДОКИ!
    Они думают они полубоги, а доллар - бог.
    Я сегодня на них злой особенно в силу этого:http://www.tasstv.com/videos/view/774
    Я против спама, но типа эти методы.....................................
    Они за свои фантики зеленые удавятся (но с другой стороны падлов этих всегда можно купить) и они будут и инфу,
    и свободу творчества и прогресс мозгов в массах зажимать и давить по макс.

    Им (особенно MS) нужны стада дЭбилов, в глазах которых доллар и только кнопка "Пуск" с прямым воздействием на мозг.
    Начни день с кнопки "Пуск" и будешь доволен! Доверь остальное нам! (с) MS.
    Они мне не братья.
    Таких давил и буду давить сколько сил будет!
    art_zh wrote:А это чтобы никто таких штучек не насобачился делать.
    Из подручных материалов. Если Когда прижмет.
    Они больше бы Задорнова "вкушали", может дойдет на 3м году и дойдет хоть что то + сказки русские про кашу с топора + историю войн на наших землях анализировали.
    Нееее... Народ который из пепла восстать может из любой мобилки сделает любой диверсионный аппарат (БЕЗ СТАНДАРТОВ!) и засунет его в зад своему врагу, вовремя и в срок и так, что 3 года думать будут, как это могло произойти???
  • Serge wrote:И в защиту SMI.
    SMI это мышки и клавы. Вы уже драйвер для EHCI+RMH написали ? Тогда не спешите хаять SMI.
    вот это и есть стратегический ход, как подсадить "на иглу" НЕЗНАЮЩИХ правды, сути.
    Это метод! Их метод!
    Вместо того, чтобы сознаться, что то надо радикально менять в BIOS уродствах, это культивируют, предвосхищают!
    А как же, Вам ведь не надо драйвера писать и думать об оптимальном решении не надо. Сделали типа свою горбатую ось и радуйтесь!
    А мы MS, пойдем дальше, дальше всех, быстрее всех...., а вы пока тут мышку глюкавенькую возюкайте, Вам же производительность не нужна?
    Зачем? Пусть мышка завесит, ядро, систему! Мышка круче ядра, круче ОСи!
    Она же завесила, значит, она хозяин положения и ситуации. Еще бы, она же SMI. А CPU баран с кольцом в ноздрях, куда его мышка + SMI определят, то с ним и будет. Песня!