Обсуждение необходимости 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 определят, то с ним и будет. Песня!
  • VaStaNi: ну да, были подозрительные копипасты. Uniflash писали ребята с rom.by, не ожидал от них такого. Но ему теперь далеко по поддержке железа, как в flashrom. Вообще, воровство кода - частая вещь. Вот эти http://www.altell.ru/products/hyperbios.html нехорошие люди тоже своровали код coreboot. Мы работаем - они воруют, и ничего не сделаешь. :(
  • XVilka
    Да, flashrom лучше.
    На rom.by больше понтов, чем полезной информации (имхо, конечно).

    Serge
    Ааа, так значит это все было ради детектирования ISA-ресурсов. Ну тогда может быть.
    Я не против APIC вообще - в таблицах, например, можно найти массу полезной информации.
    Просто есть совсем другой подход - взгляни на структуру устройств в CoreBoot. Хочешь узнать ресурсы ISA, не доверяешь PnP - прочитай регистры SIO,там же все записано как оно реально есть!
    И этих SIO-чипов совсем немного (во всяком случае, меньше чем чипсетов); почти все они прекрасно документрованы и функционально-однотипны.

    Но ISA - это уже прошлый век. Уже по крайней мере 5 лет как всю железную информацию можно читать через PCIe Extended Configspace. И PM там есть, и SMI, и хотплаг, и PnP, и даже диагностика ошибок - всё.

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

    SII
    Конфликт интересов не только со мной - yogev_ezra тоже по-своему гребет против течения, но его почему-то никто демагогом не называет, и в длинный бан отправлять не собираются. А вот мы с VaStaNi явно не ко двору пришлись. Ну да ладно, если хоть 100 начинающих программеров здесь наши посты прочитают - значит все не зря. Может хоть у кого-то где-то некогеррентный бит и установится :wink:
    Насчет того, что
    а) нет иного универсального способа обнаружения всех устройств, расположенных на материнке; б) нет иного универсального способа управлять энергопотреблением, вентиляторами и прочими фишками из этой области.
    - вот это как раз демагогия как она есть. Такого "универсального" способа вообще нет! Если хотя бы где-то и на чем-то ACPI не работает (увы, это так) - значит он уже неуниверсален. А другие неуниверсальные способы есть, причем они проще и гораздо надежнее.
    В защиту сисфункций MeOS: там конечно бардак, но ничуть не хуже других. Сисфункции линукса лучше? Сейчас - может быть, сообщество стало более мудрым и ответственным. Но первые номера - это же просто шиза была какая-то. В Колибри та же тенденция: до 50-х функций - ващще дурдом, потом - вполне приличный уровень.
  • art_zh wrote: Конфликт интересов не только со мной - yogev_ezra тоже по-своему гребет против течения, но его почему-то никто демагогом не называет
    Ну, Вас я тоже демагогом не называю. Просто я считаю, что IA-32 в системах РВ делать вообще нечего и лучше было бы делать Вашу работу на чём-нибудь более вменяемом, ну да это в данном случае полный оффтоп :)
    Насчет того, что
    а) нет иного универсального способа обнаружения всех устройств, расположенных на материнке; б) нет иного универсального способа управлять энергопотреблением, вентиляторами и прочими фишками из этой области.
    - вот это как раз демагогия как она есть. Такого "универсального" способа вообще нет! Если хотя бы где-то и на чем-то ACPI не работает (увы, это так) - значит он уже неуниверсален
    А вот тут позвольте с Вами не согласиться. Винда, как известно, активно использует этот самый ACPI, и эта самая Винда работает на любом более-менее современном ПК. Следовательно, имеющаяся в материнках этих ПК реализация ACPI вполне себе корректна и позволяет достичь желаемого эффекта. Если же на какой-то древней, особо кривой или жутко специализированной матери Винда работать не в состоянии из-за кривизны тамошней реализации ACPI (или вообще отсутствия таковой), то такой факт, хотя и даёт формальный повод говорить о неуниверсальности ACPI, на деле для абсолютного большинства людей никакой роли не играет, и учитывать существование подобных изделий в ОС, рассчитанной на массовый рынок обычных ПК, просто нет никакой необходимости.
    А другие неуниверсальные способы есть, причем они проще и гораздо надежнее.
    Но только они куда неуниверсальнее, чем ACPI. Ну а городить в системе тыщу разных способов что-то там узнать, когда в 99,9% случаев достаточно одного, пусть и довольно сложного в реализации... Нафиг оно надо? Проще плюнуть на этот самый 0,1%, ну а кому он нужен, тот пусть сам с ним и заморачивается :)
    В защиту сисфункций MeOS: там конечно бардак, но ничуть не хуже других. Сисфункции линукса лучше? Сейчас - может быть, сообщество стало более мудрым и ответственным. Но первые номера - это же просто шиза была какая-то. В Колибри та же тенденция: до 50-х функций - ващще дурдом, потом - вполне приличный уровень.
    Линух ужасен, как и любой Уних вообще (откуда ноги, собственно, и растут). Но это лишь подтверждает мой тезис о том, что, как ни делай прекрасно систему внутри, дерьмовый API этим не исправишь, ну а чтобы его привести в норму, нужны кардинальные хирургические методы, сопряжённые с полной потерей совместимости (ну или с костылями в виде прослоек, которые древний кривой АПИ эмулируют на новом вменяемом). Кстати, когда я узнал, что в Линухе нет обычного асинхронного ввода-вывода, я чуть со стула не грохнулся. Это же дикое усложнение системы (делать вытесняемое ядро и всё такое) и одновременное ухудшение функционала! Так что у господ K&R (принудительная синхронность ввода-вывода ведь из Униха идёт) мозговой разжиж не только в части языков программирования... Впрочем, это меня опять на флудерастизм и злостный оффтоп потянуло :)
  • VaStaNi, вы сами себе противоречите. ACPI - это отнюдь не только список устройств с используемыми ресурсами. ACPI - это в первую очередь средство, позволяющее операционной системе сказать железу "здравствуй, я современная операционная система, знающая, как обрабатывать всевозможные срочные события, и о них нужно рассказывать мне, а не SMI". ACPI придуман именно для того, чтобы избавиться от SMI, - поэтому acpica столь велика, собственно разбор таблиц и получение списка устройств - это ерунда, основная сложность в куче новых событий, которые нужно обрабатывать. Так что, по вашей же логике, вы должны повсеместно агитировать за использование ACPI.
    У art_zh хоть позиция последовательная, просто он не тот форум выбрал для агитации - если бы вместо Колибри такой, какая она есть сейчас, развивалась бы Kolibri-I для какого-нибудь интеловского чипсета, то фиг бы он вообще ей заинтересовался.

    "Вот поэтому эти сссссукииииии жмут ДОКИ!" - вам кто-то зажал доки на EHCI или на ACPI? В этих доках открытым текстом написано, как именно операционная система может выключить перенаправление соответствующих вещей в SMI.

    "вот это и есть стратегический ход, как подсадить "на иглу" НЕЗНАЮЩИХ правды, сути. Вместо того, чтобы сознаться, что то надо радикально менять в BIOS уродствах, это культивируют, предвосхищают!" - где предвосхищают? Чем культивируют, тем, что в половине BIOSов это не работает? Наоборот, информация об EHCI открыта, всё стимулирует её реализовывать вместо того, чтобы полагаться на SMI, вот вас Serge и спрашивает, сделали вы хоть что-нибудь - по совершенно открытой информации! - чтобы возмущаться SMI. Если не сделали, то ваше возмущение выглядит... скажем так, не очень приятно выглядит.
    Сделаем мир лучше!
  • CleverMouse
    Если бы полтора года назад существовала "прямая" ветка Колибри для Intel Atom, то я бы обязательно к ней присоединился.
    eBox появился позже. Но если бы он тянул мои задачи - я бы с энузиазмом вошел в группу yogev_ezrы.
    Надо было выбрать какую-то одну целевую платформу для встраиваемой КОС - я выбрал недорогую, перспективную и хорошо документированную AMD.
    Теперь уже конечно поздно сворачивать на другие платформы. Но и не нужно - А-версия работает на Fusion - а это новый лидер на встраиваемом х86-рынке.
    Сейчас кругом застой, но я очень надеюсь на взрывной рост интереса к Fusion-системам в будущем году.

    Коллеги,мы делаем одно дело (пусть и с разных сторон) - хватит ругаться.
  • art_zh wrote:CleverMouse
    Если бы полтора года назад существовала "прямая" ветка Колибри для Intel Atom, то я бы обязательно к ней присоединился.
    eBox появился позже. Но если бы он тянул мои задачи - я бы с энузиазмом вошел в группу yogev_ezrы.
    Надо было выбрать какую-то одну целевую платформу для встраиваемой КОС - я выбрал недорогую, перспективную и хорошо документированную AMD.
    Теперь уже конечно поздно сворачивать на другие платформы. Но и не нужно - А-версия работает на Fusion - а это новый лидер на встраиваемом х86-рынке.
    Сейчас кругом застой, но я очень надеюсь на взрывной рост интереса к Fusion-системам в будущем году.

    Коллеги,мы делаем одно дело (пусть и с разных сторон) - хватит ругаться.
    Согласен, но нужна общая стротегия, а не разброс на AMD и Intel.
    Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!
  • Who is online

    Users browsing this forum: No registered users and 7 guests