Board.KolibriOS.org

А в больших ОС как выкручиваются?

А в больших все используют ACPI. У Майкрософт своя реализация, Эппл не знаю, а для остальных есть интеловская acpica. Все опенсорс оси делятся на те где есть acpica, и те где нет ACPI.

Я привел лишь для примера путь, как вариант, как люди ходят и успешно решают проблему(ы).
"Содержит"? Ты хош сказать про нарушение лицензии? Дебаг и копипаст? Не в курсе. Знаю, что UniFlash лежал долго брошенным и "подотстал" одно время от железа, но потом вроде наши ребятки подсуетились и что то там подобавляли в основном впролне успешно вроде (работает).
НЕ недо-acpi, а что нибудь а-ля ACPI-KOS
Я понял так, что ты категорически против нестандартных методов и своих технологий.
Хотя надо признать, ведь цель рождает стредства, так? Тогда Цель должна оправдывать себя по сути по максимуму по эффективности.
Нужно понимание зачем нужен собственно ACPI.
Если чтобы на любой платформе выключать питание, то это много работы и мало эффекта с учетом массы недостатков и горбыльностей,
а я вообще против SMI, как теневого и по сути паразитического механизма.
Это раковая опухоль на размеренном пульсе сердца ОСи, хаотически пожирающая пачками кванты оси времени процессов.
Это вообще "безсознательное состояние ОСи" помните, как у доцента джентльменов удачи: "тут все помню, а тут ничего не помню" и порой аж целых 5-10мс!
Проц нихрена не знает, что с ним было и где собственно он был! Ах...еть! ВСЕ прерывания отложены и некоторые просрочены!!!
Он (CPU) тупо не помнит, т.к. ему "дали по голове дубиной SMI" и он в ....!!!
Для современных процессоров 5-10мс - это капец 21 века!
И 1мс "безсознанки CPU" - это тоже капец, если не гавном в ОСестроении заниматься.
Сейчас не каменный век, чтобы закрывать глаза на такое, по крайней мере я так не могу.
Имхо выводы.
Быдлокод в обработчике SMI тому причина, а особенно "кодерские" конструкции ожиданий и временные выдержки для медленных девайсов XT машин (даже не AT) типа (упрощенно, но суть идиотизма сохранена):

   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!
И на это закрывать глаза, успокаивать себя волшебным словом "стандарт"!? Нет, это для меня сугубый перебор, аборигеново решение, эти типа технологии и такой типа кодинг - нафиГ!
Я против этой срани, во всяком случае пока все не изменится в гуманную сторону. Вот любопытно, как там в несколькими ядрами дела... Хоть бы кто нить расказал, исследовал и рассказал. Жаль времени нет...
Ну ты так и не сказал и похоже не описал (где читать?), что такое нумератор в твоем видении вообще? Нумератор всего и всех? Это перебор и нереальности. Где границы?
Вот выше сказал конкретно так: "нумеровать ISA".
Хорошо зацепка есть, есть граница, предел.
Так вот то, что я привел с головой хватит. Проверял, смотрел.
Сличал свои результаты по данному делу с тестовой программулиной ASTRA (рекомендую)
Вот собственно типажные вещи, что может (должна) получать ОСь, как я считаю, при загрузке, вернее "развороте и оживанию ядра" (stage_1), еще никакие IDT, GDT не имеют права на жизнь...
Тут ОСь еще только "готовится к господству" над всеми и вся, осматривает свои будующие владения, дабы юзать их правильно, рационально или просто знать, что это есть и учтено его наличие...



вот и нумерация и ресурсы и параметры... не все?
Наверное.
Не так приведены?
Ну и что, тансформируем в свое и потом пересечение методов даст полноту.
Главное ЭТО УЖЕ ЕСТЬ! Его уже знает BIOS(знал BIOS при POST тестинге)
Лишним инфа быть НЕ может, она может быть куцей, это да, но лучше чтото чем ничего! Факт и ИмХо! Хо Хо Хо!

ISA? А надо?

Для энумерации устройств и раскидывания прерываний - да, используют. А вот дальше...
А дальше для чего-то им нужны драйвера, в т.ч и для чипсетов ("Обнаружено новое устройство. Вставьте диск...").
А кое-кому даже и PM-драйвера ("Только у нас! Новинка сезона! Установи PowerNOW! и больше не перегревайся...")

теперь 2 вопроса на засыпку:
1) если у нас есть свои драйвера чипсета, то на кой этот ACPI вообще сдался?
2) если у нас нет драйверов чипсета, то нафиг нам ACPI? (ах, да - прерывания и шатдаун, это конечно крутизна... и вообще - почти как у взрослых)


А это чтобы никто таких штучек не насобачился делать.
Из подручных материалов. Если Когда прижмет.

art_zh
Ну если всё так с дровами замечательно то нафига тогда в Майкрософт эту ACPI придумали ? И не на пустом месте ведь возникла. Прямая наследница разных PnP ISA и даже PnP коды устройств знает. Меня не особо интересует управление питанием, заряд батареи, подсветка экрана, мониторинг температуры и прочие фичи доступные через acpi. А вот определение устройств с ресурсами интересует очень. И в этом ACPI представляется мне единственным универсальным средством. Вот в логе сразу видно какие устройства ISA есть на материнской плате, какие порты используются. Это только небольшая часть доступной информации. Адреса apic, число процессоров, роутинг прерываний, всё видно через ACPI.
Есть на замену универсальное решение ?

И в защиту SMI.
SMI это мышки и клавы. Вы уже драйвер для EHCI+RMH написали ? Тогда не спешите хаять SMI.

А тут имеет место быть "конфликт интересов". art_zh занимается встраиваемыми системами, которые должны работать в реальном времени -- а с такими задачами ACPI совмещается, так скажем, плохо (разве что для начального поиска устройств, да и то под вопросом, ведь надо гарантировать, что никакого гадского кода SMM после инициализации системы выполняться точно не будет, иначе о реальном времени можно забыть). Кроме того, в таких задачах, вообще говоря, набор оборудования известен заранее, и именно под него создаётся (ну или "дорабатывается напильником") ОС; соответственно, нет нужды что-то там в процессе начальной загрузки определять.

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

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

Кстати, об унификации. Что МеОС (а значит, и выросшая оттуда КОС) представляет из себя полный бардак, мне стало ясно без того, чтобы смотреть на исходники, достаточно было увидеть список системных функций. В одну кучу свалено всё подряд, никакой системы нет, на новый тип устройств надо изобретать новые системные вызовы... Похоже, этот самый Вилле идеальным подходом к созданию АПИ для ОС считал путь, принятый в БИОС, где, как известно, имеется миллион функций, добавленных когда попало и кем попало, причём обычно без малейших попыток задуматься о будущем хотя бы на ближайшие 5 лет. Конечно, изнутри весь этот хаос можно реализовать очень эффективно, но в итоге всё равно получится хаос -- только оптимизированный.

Даже если бы не дрова, а только путные доки!
Вот поэтому эти сссссукииииии жмут ДОКИ!
Они думают они полубоги, а доллар - бог.
Я сегодня на них злой особенно в силу этого:http://www.tasstv.com/videos/view/774
Я против спама, но типа эти методы.....................................
Они за свои фантики зеленые удавятся (но с другой стороны падлов этих всегда можно купить) и они будут и инфу,
и свободу творчества и прогресс мозгов в массах зажимать и давить по макс.

Им (особенно MS) нужны стада дЭбилов, в глазах которых доллар и только кнопка "Пуск" с прямым воздействием на мозг.
Начни день с кнопки "Пуск" и будешь доволен! Доверь остальное нам! (с) MS.
Они мне не братья.
Таких давил и буду давить сколько сил будет!

Они больше бы Задорнова "вкушали", может дойдет на 3м году и дойдет хоть что то + сказки русские про кашу с топора + историю войн на наших землях анализировали.
Нееее... Народ который из пепла восстать может из любой мобилки сделает любой диверсионный аппарат (БЕЗ СТАНДАРТОВ!) и засунет его в зад своему врагу, вовремя и в срок и так, что 3 года думать будут, как это могло произойти???

вот это и есть стратегический ход, как подсадить "на иглу" НЕЗНАЮЩИХ правды, сути.
Это метод! Их метод!
Вместо того, чтобы сознаться, что то надо радикально менять в 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 начинающих программеров здесь наши посты прочитают - значит все не зря. Может хоть у кого-то где-то некогеррентный бит и установится
Насчет того, что - вот это как раз демагогия как она есть. Такого "универсального" способа вообще нет! Если хотя бы где-то и на чем-то ACPI не работает (увы, это так) - значит он уже неуниверсален. А другие неуниверсальные способы есть, причем они проще и гораздо надежнее.
В защиту сисфункций MeOS: там конечно бардак, но ничуть не хуже других. Сисфункции линукса лучше? Сейчас - может быть, сообщество стало более мудрым и ответственным. Но первые номера - это же просто шиза была какая-то. В Колибри та же тенденция: до 50-х функций - ващще дурдом, потом - вполне приличный уровень.

Ну, Вас я тоже демагогом не называю. Просто я считаю, что IA-32 в системах РВ делать вообще нечего и лучше было бы делать Вашу работу на чём-нибудь более вменяемом, ну да это в данном случае полный оффтоп



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



Но только они куда неуниверсальнее, чем ACPI. Ну а городить в системе тыщу разных способов что-то там узнать, когда в 99,9% случаев достаточно одного, пусть и довольно сложного в реализации... Нафиг оно надо? Проще плюнуть на этот самый 0,1%, ну а кому он нужен, тот пусть сам с ним и заморачивается



Линух ужасен, как и любой Уних вообще (откуда ноги, собственно, и растут). Но это лишь подтверждает мой тезис о том, что, как ни делай прекрасно систему внутри, дерьмовый 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-системам в будущем году.

Коллеги,мы делаем одно дело (пусть и с разных сторон) - хватит ругаться.

Согласен, но нужна общая стротегия, а не разброс на AMD и Intel.

_________________
Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!