Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн дек 11, 2017 4:18 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 70 сообщений ]  На страницу Пред. 1 2 3 4 5 След.
Автор Сообщение
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 5:04 pm 
А в больших ОС как выкручиваются?


Вернуться к началу
   
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 8:17 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
А в больших все используют ACPI. У Майкрософт своя реализация, Эппл не знаю, а для остальных есть интеловская acpica. Все опенсорс оси делятся на те где есть acpica, и те где нет ACPI.


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 8:35 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
XVilka писал(а):
uniflash содержит куски кода, позаимствованные без спроса у flashrom http://www.flashrom.org/
Я привел лишь для примера путь, как вариант, как люди ходят и успешно решают проблему(ы).
"Содержит"? Ты хош сказать про нарушение лицензии? Дебаг и копипаст? Не в курсе. Знаю, что UniFlash лежал долго брошенным и "подотстал" одно время от железа, но потом вроде наши ребятки подсуетились и что то там подобавляли в основном впролне успешно вроде (работает).
Serge писал(а):
VaStaNi
Вместо одной acpi предлагается пять недо-acpi. Спасибо.
НЕ недо-acpi, а что нибудь а-ля ACPI-KOS :D
Я понял так, что ты категорически против нестандартных методов и своих технологий.
Хотя надо признать, ведь цель рождает стредства, так? Тогда Цель должна оправдывать себя по сути по максимуму по эффективности.
Нужно понимание зачем нужен собственно ACPI.
Если чтобы на любой платформе выключать питание, то это много работы и мало эффекта с учетом массы недостатков и горбыльностей,
а я вообще против SMI, как теневого и по сути паразитического механизма.
Это раковая опухоль на размеренном пульсе сердца ОСи, хаотически пожирающая пачками кванты оси времени процессов.
Это вообще "безсознательное состояние ОСи" помните, как у доцента джентльменов удачи: "тут все помню, а тут ничего не помню" и порой аж целых 5-10мс!
Проц нихрена не знает, что с ним было и где собственно он был! Ах...еть! ВСЕ прерывания отложены и некоторые просрочены!!!
Он (CPU) тупо не помнит, т.к. ему "дали по голове дубиной SMI" и он в ....!!! :mrgreen:
Для современных процессоров 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!
И на это закрывать глаза, успокаивать себя волшебным словом "стандарт"!? Нет, это для меня сугубый перебор, аборигеново решение, эти типа технологии и такой типа кодинг - нафиГ!
Я против этой срани, во всяком случае пока все не изменится в гуманную сторону. Вот любопытно, как там в несколькими ядрами дела... Хоть бы кто нить расказал, исследовал и рассказал. Жаль времени нет...
Serge писал(а):
Покажите плиз нумератор работающий на всех х86 платформах начиная с Pentium.
Ну ты так и не сказал и похоже не описал (где читать?), что такое нумератор в твоем видении вообще? Нумератор всего и всех? Это перебор и нереальности. Где границы?
Вот выше сказал конкретно так: "нумеровать ISA".
Хорошо зацепка есть, есть граница, предел.
Так вот то, что я привел с головой хватит. Проверял, смотрел.
Сличал свои результаты по данному делу с тестовой программулиной ASTRA (рекомендую)
Вот собственно типажные вещи, что может (должна) получать ОСь, как я считаю, при загрузке, вернее "развороте и оживанию ядра" (stage_1), еще никакие IDT, GDT не имеют права на жизнь...
Тут ОСь еще только "готовится к господству" над всеми и вся, осматривает свои будующие владения, дабы юзать их правильно, рационально или просто знать, что это есть и учтено его наличие...
Изображение
Изображение
Изображение
вот и нумерация и ресурсы и параметры... не все?
Наверное.
Не так приведены?
Ну и что, тансформируем в свое и потом пересечение методов даст полноту.
Главное ЭТО УЖЕ ЕСТЬ! Его уже знает BIOS(знал BIOS при POST тестинге)
Лишним инфа быть НЕ может, она может быть куцей, это да, но лучше чтото чем ничего! Факт и ИмХо! Хо Хо Хо! :)


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 9:44 pm 
Не в сети

Зарегистрирован: Пн сен 26, 2011 3:01 pm
Сообщения: 33
Serge писал(а):
VaStaNi
Вместо одной acpi предлагается пять недо-acpi. Спасибо.
Покажите плиз нумератор работающий на всех х86 платформах начиная с Pentium.


ISA? А надо?


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 9:53 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge писал(а):
А в больших все используют ACPI. У Майкрософт своя реализация, Эппл не знаю, а для остальных есть интеловская acpica. Все опенсорс оси делятся на те где есть acpica, и те где нет ACPI.
Для энумерации устройств и раскидывания прерываний - да, используют. А вот дальше...
А дальше для чего-то им нужны драйвера, в т.ч и для чипсетов ("Обнаружено новое устройство. Вставьте диск...").
А кое-кому даже и PM-драйвера ("Только у нас! Новинка сезона! Установи PowerNOW! и больше не перегревайся...") :lol:

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

VaStaNi писал(а):
а я вообще против SMI, как теневого и по сути паразитического механизма.
Это раковая опухоль на размеренном пульсе сердца ОСи, хаотически пожирающая пачками кванты оси времени процессов. (в цитатник)
Это вообще "безсознательное состояние ОСи" помните, как у доцента джентльменов удачи: "тут все помню, а тут ничего не помню" и порой аж целых 5-10мс!

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


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 10:22 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh
Ну если всё так с дровами замечательно то нафига тогда в Майкрософт эту ACPI придумали ? И не на пустом месте ведь возникла. Прямая наследница разных PnP ISA и даже PnP коды устройств знает. Меня не особо интересует управление питанием, заряд батареи, подсветка экрана, мониторинг температуры и прочие фичи доступные через acpi. А вот определение устройств с ресурсами интересует очень. И в этом ACPI представляется мне единственным универсальным средством.
Спойлер: Показать
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.


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 10:52 pm 
Не в сети

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

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 11:13 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
art_zh писал(а):
1) если у нас есть свои драйвера чипсета, то на кой этот ACPI вообще сдался?
Даже если бы не дрова, а только путные доки!
Вот поэтому эти сссссукииииии жмут ДОКИ!
Они думают они полубоги, а доллар - бог.
Я сегодня на них злой особенно в силу этого:http://www.tasstv.com/videos/view/774
Я против спама, но типа эти методы.....................................
Они за свои фантики зеленые удавятся (но с другой стороны падлов этих всегда можно купить) и они будут и инфу,
и свободу творчества и прогресс мозгов в массах зажимать и давить по макс.

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

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


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Чт сен 29, 2011 11:24 pm 
Не в сети
Just Flooding
Аватара пользователя

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


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Пт сен 30, 2011 12:58 am 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
VaStaNi: ну да, были подозрительные копипасты. Uniflash писали ребята с rom.by, не ожидал от них такого. Но ему теперь далеко по поддержке железа, как в flashrom. Вообще, воровство кода - частая вещь. Вот эти http://www.altell.ru/products/hyperbios.html нехорошие люди тоже своровали код coreboot. Мы работаем - они воруют, и ничего не сделаешь. :(


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Пт сен 30, 2011 2:30 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
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-х функций - ващще дурдом, потом - вполне приличный уровень.


Вернуться к началу
 Заголовок сообщения: Re: Выключение ПК.
СообщениеДобавлено: Пт сен 30, 2011 3:10 am 
Не в сети

Зарегистрирован: Ср дек 26, 2007 5:09 am
Сообщения: 214
art_zh писал(а):
Конфликт интересов не только со мной - yogev_ezra тоже по-своему гребет против течения, но его почему-то никто демагогом не называет


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

Цитата:
Насчет того, что
Цитата:
а) нет иного универсального способа обнаружения всех устройств, расположенных на материнке; б) нет иного универсального способа управлять энергопотреблением, вентиляторами и прочими фишками из этой области.
- вот это как раз демагогия как она есть. Такого "универсального" способа вообще нет! Если хотя бы где-то и на чем-то ACPI не работает (увы, это так) - значит он уже неуниверсален


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

Цитата:
А другие неуниверсальные способы есть, причем они проще и гораздо надежнее.


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

Цитата:
В защиту сисфункций MeOS: там конечно бардак, но ничуть не хуже других. Сисфункции линукса лучше? Сейчас - может быть, сообщество стало более мудрым и ответственным. Но первые номера - это же просто шиза была какая-то. В Колибри та же тенденция: до 50-х функций - ващще дурдом, потом - вполне приличный уровень.


Линух ужасен, как и любой Уних вообще (откуда ноги, собственно, и растут). Но это лишь подтверждает мой тезис о том, что, как ни делай прекрасно систему внутри, дерьмовый API этим не исправишь, ну а чтобы его привести в норму, нужны кардинальные хирургические методы, сопряжённые с полной потерей совместимости (ну или с костылями в виде прослоек, которые древний кривой АПИ эмулируют на новом вменяемом). Кстати, когда я узнал, что в Линухе нет обычного асинхронного ввода-вывода, я чуть со стула не грохнулся. Это же дикое усложнение системы (делать вытесняемое ядро и всё такое) и одновременное ухудшение функционала! Так что у господ K&R (принудительная синхронность ввода-вывода ведь из Униха идёт) мозговой разжиж не только в части языков программирования... Впрочем, это меня опять на флудерастизм и злостный оффтоп потянуло :)


Вернуться к началу
 Заголовок сообщения: Re: Обсуждение необходимости ACPI
СообщениеДобавлено: Пт сен 30, 2011 4:07 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
VaStaNi, вы сами себе противоречите. ACPI - это отнюдь не только список устройств с используемыми ресурсами. ACPI - это в первую очередь средство, позволяющее операционной системе сказать железу "здравствуй, я современная операционная система, знающая, как обрабатывать всевозможные срочные события, и о них нужно рассказывать мне, а не SMI". ACPI придуман именно для того, чтобы избавиться от SMI, - поэтому acpica столь велика, собственно разбор таблиц и получение списка устройств - это ерунда, основная сложность в куче новых событий, которые нужно обрабатывать. Так что, по вашей же логике, вы должны повсеместно агитировать за использование ACPI.
У art_zh хоть позиция последовательная, просто он не тот форум выбрал для агитации - если бы вместо Колибри такой, какая она есть сейчас, развивалась бы Kolibri-I для какого-нибудь интеловского чипсета, то фиг бы он вообще ей заинтересовался.

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

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

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Обсуждение необходимости ACPI
СообщениеДобавлено: Пт сен 30, 2011 4:58 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
CleverMouse
Если бы полтора года назад существовала "прямая" ветка Колибри для Intel Atom, то я бы обязательно к ней присоединился.
eBox появился позже. Но если бы он тянул мои задачи - я бы с энузиазмом вошел в группу yogev_ezrы.
Надо было выбрать какую-то одну целевую платформу для встраиваемой КОС - я выбрал недорогую, перспективную и хорошо документированную AMD.
Теперь уже конечно поздно сворачивать на другие платформы. Но и не нужно - А-версия работает на Fusion - а это новый лидер на встраиваемом х86-рынке.
Сейчас кругом застой, но я очень надеюсь на взрывной рост интереса к Fusion-системам в будущем году.

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


Вернуться к началу
 Заголовок сообщения: Re: Обсуждение необходимости ACPI
СообщениеДобавлено: Пт сен 30, 2011 10:08 pm 
Не в сети
Аватара пользователя

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

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


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

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 70 сообщений ]  На страницу Пред. 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB