В свете поднятой (http://threatpost.com/three-things-to-take-away-from-cansecw...) на конференции CanSecWest темы внедрения шпионского и вердоносного ПО в BIOS и прошивки, Марк Шаттлворт призвал (http://www.markshuttleworth.com/archives/1332) сообщество и производителей изменить подход к использованию проприетарных прошивок и ACPI. Во многих системах для управления питанием осуществляется обращение к вызовам ACPI, что приводит к выполнению кода, проверить который затруднительно. Поэтому, прошивки воспринимаются как наиболее лакомый объект для попыток внедрения шпионского кода (вывод делается на основе опубликованного Сноуденом каталога шпионского ПО от АНБ), который может быть активирован даже при выполнении на компьютере полностью надёжной и проверенной операционной системы.
Марк предлагает производителям перейти к практике применения пассивных прошивок, которые предоставляют данные об организации взаимодействия с оборудованием и описывают зависимости, но не включают в себя исполняемый код. Код для управления оборудованием при этом предлагается интегрировать непосредственно в ядро операционной системы, без обращения к прослойкам, таким как ACPI.
URL: http://www.markshuttleworth.com/archives/1332
Новость: http://www.opennet.me/opennews/art.shtml?num=39332
Ну всё-таки сама идея прятать код под стандартный API весьма здравая и тянуть в ядро ещё кучу кода под разные мамки -- гиблое дело.
Просто этот код должен быть открытым.
Даёшь coreboot на все мамки!
Точнее не так (предыдущий лозунг нелеп, поскольку невозможен) -- даёшь coreboot на десяток-другой хороших плат, а остальные платы пусть идут лесом кормить хомяков и неуловимых Джо!
> Точнее не так (предыдущий лозунг нелеп, поскольку невозможен) -- даёшь coreboot на
> десяток-другой хороших плат, а остальные платы пусть идут лесом кормить хомяков
> и неуловимых Джо!+500100
И процессоры на 155ЛА7
> 155ЛА7155ЛА3 хватит всем.
> И процессоры на 155ЛА7Во как тебя торкнуло, что такой бред пишешь...
Кстати, так и было! В 80-х годах был такой журнал - "Микропроцессорные средства и системы". В одном из номеров была опубликована на только схема, но и разведённые платы CPU, выполненного на 155 наборе. Собранный модуль был примерно с кирпич. :)
Процессор на 155 серии размером с кирпич?! Разве что мегалитический, от пирамиды Хеопса...
От аспи даже мс в вын8 отказалась.
Как правило это совершенно левый код, написанный неизвестно кем по заказу (ли? Скорее всего просто взятый по принципу "вроде работает") производителя материлок, который никто и не соберается меняет (и даже задумываться о его работоспособности. Да и код закрыт, а платить из-за небольшого удешевления производства дураков нет) в случае "небольшой" модификации материлки.
И это только о качестве этого (закрытого) кода. Про спай-варе даже речи не доходит.
зыж
Опять же, про вот эти баги (и их воркэраунды в ядре) уже молчу:
> # dmesg | grep -i "Firmware Bug"
> [ 0.251500] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> [ 2.312124] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS(Не говоря уже про "ACPI Warning")
Уж лучше пусть в ядре будет полностью драйвер (который можно отлаживать, дебажить и исправлять. И опять же, не тебе же это делать?), чем набор (большой набор, для каждой модели материнки, ноута) костылей-воркэраундов, в которых комменты в стиле "хрен его знает зачем, но этот ноут работает только вот с этим магик-значением".
Ну понятно, что реализация через жопу, но идея-то таки здравая:)
С чего вдруг она здравая?
Вот если бы создали альянс по предоставлению драйверов в опен-сорс виде с опенсорсным стандартом на АПИ, вот тогда бы да, она бы была здравой.А так — никто ни за что не отвечает, блоб, прайваси, секурити, отсутствие возможности не то что дебагинга, а даже тестирования,…
Полная хрень вызванная желанием проприерастов «как бы сделать так, чтобы и блобы остались, но всё-таки работало бы с системой, которая вАААще ни в курсе дела».
С криками со стороны АНБ/этк — «Да-да! Было бы круто.»
Специально для клоунов повторяю:
> # dmesg | grep -i "Firmware Bug"
> [ 0.251500] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignoredДля управления питанием (см. P в ACPI) необходимо и достаточно иметь открытое АПИ и всё.
Или, если вы злостный проприетарь, реализуйте в блобе драйвера (как показано на примере backlight в вын8).
Совершенно не обязательно делить этот блоб на 2-е части и поставлять отдельно на радость разве что АНБ и мс (см. Firmware Bug ваше), для поддержки продуктов которой у железячников (вау, идея acpi — заставить железячников писать софт. А подмести вам в доме не нужно?) с трудом хватает и сил, и желания.
Спецификация на ACPI открыта. Как бы она не называлась, ACPI нужна не только для управления электропитанием.Ну а для тех, кто не в теме, я переведу на русский:
> [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
Функция OSI используется чтобы определить какой именно функционал поддерживает ОС. В зависимости от этого, в таблицы ACPI будет (или не будет) добавлена информация о backlight и пр. Если этот вызов будет игнорироваться ОС (что и произошло, судя по логу), то ACPI вернёт минимум чтобы не допустить повреждения оборудования. В ряде случаев, ОС может вернуть, что она уже умеет работать с оборудованием (напр. есть драйвер backlights) и помощь ACPI ей в этом не нужна.
Т.к. Линукс крайне некорректно работает с оборудованием (см. сгоревшие ноуты и поломаные мат.платы), то часто BIOS отключает многие функции, которые Линукс гарантированно (в ходе тестов вендора) повреждает. Разработчикам Линукс это ну очень не нравится и они считают что это вселенский заговор, ошибка в прошивке ("firmware bug"), АНБ, инопланетяне, и т.п.
> Т.к. Линукс крайне некорректно работает с оборудованием (см. сгоревшие ноуты и поломаные мат.платы)Где смотреть? Может, линукс еще и кофе на клавиатуры проливает?
> часто BIOS отключает многие функции, которые Линукс гарантированно (в ходе тестов вендора) повреждает.Именно Линукс? А что насчёт BSD (... список из семейства)? ReactOS? OpenIndiana? И, кстати, что за Линукс имеется в виду? ну можно первую сотню с distrowatch.com и напротив галочки - с чем тестировали.
Ну, понятное дело, я ёрничаю. Понятное дело никакие тесты с линуксом не проводятся и этот бред ты просто взял и придумал. Не надо так. Не хорошо это.
А что вы от клоуна хотели?
> А что вы от клоуна хотели?Ну....а может он про Haiku слышал? :)
Приведи хоть одну причину, зачем я должен что-то доказывать? Не веришь что параллельные прямые тоже могут пересекаться - мне всё равно :).
> Приведи хоть одну причину, зачем я должен что-то доказывать? Не веришь что
> параллельные прямые тоже могут пересекаться - мне всё равно :).Э... не хочешь подтвердить свои слова- будем считать их фантазией. делов-то.
>> [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> Функция OSI используется чтобы определить какой именно функционал поддерживает ОС.Угу,[Firmware Bug] переведи, клоун.
Зыж
Звание самого тyпoгo тролля ты заработал по праву.
>самого тyпoгo тролляНо, улов. Но, разлёт! Не-не, девидблейн, методичка у него хорошая, забористая.
>[оверквотинг удален]
> о backlight и пр. Если этот вызов будет игнорироваться ОС (что
> и произошло, судя по логу), то ACPI вернёт минимум чтобы не
> допустить повреждения оборудования. В ряде случаев, ОС может вернуть, что она
> уже умеет работать с оборудованием (напр. есть драйвер backlights) и помощь
> ACPI ей в этом не нужна.
> Т.к. Линукс крайне некорректно работает с оборудованием (см. сгоревшие ноуты и поломаные
> мат.платы), то часто BIOS отключает многие функции, которые Линукс гарантированно (в
> ходе тестов вендора) повреждает. Разработчикам Линукс это ну очень не нравится
> и они считают что это вселенский заговор, ошибка в прошивке ("firmware
> bug"), АНБ, инопланетяне, и т.п.Как правило, Линукс некорректно работает с оборудованием только после того, как ACPI код определит при помощи _OSI(Linux) , что имеет дело с Linux, после чего преднамеренно включает предопределённые вредоносные вещи. По каковой причине и было сделано так, что эта попытка определения Linux не срабатывает, и выводится отмеченное выше сообщение о Firmware Bug.
> Спецификация на ACPI открыта. Как бы она не называлась, ACPI нужна не
> только для управления электропитанием....но и для того, что бы помешать запуску _всего(1), кроме Windows-а (местами mjg59.dreamwidth.org/29954.html OSX-а).
RedHat хочет посидеть на незанятом месте "друга вендоров #1 в номинации ACPI" в ARM-серверах, а Марк выступает с критикой. Разговоры дёшевы.
> Т.к. Линукс крайне некорректно работает с оборудованием (см. сгоревшие ноуты и поломаные
> мат.платы), то часто BIOS отключает многие функции, которые Линукс гарантированно (в
> ходе тестов вендора) повреждает.Во, тролище-то. И всё на голу бом глазу, с пион ерским присвистом. Ловец! П.(1) в действии.
>> # dmesg | grep -i "Firmware Bug"
>> [ 0.251500] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>> [ 2.312124] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOSСтало интересно, вот еще. Возможно, какие-то из мест в свою очередь обертки, это не проверял.
$ git g -c FW_BUG
arch/x86/kernel/apic/apic.c:2
arch/x86/kernel/cpu/amd.c:1
arch/x86/kernel/cpu/cpufreq/powernow-k8.c:15
arch/x86/kernel/cpu/mcheck/mce_amd.c:2
arch/x86/kernel/cpu/perf_event.c:1
arch/x86/oprofile/op_model_amd.c:4
arch/x86/pci/mmconfig-shared.c:1
drivers/acpi/apei/apei-base.c:3
drivers/acpi/apei/einj.c:2
drivers/acpi/apei/erst.c:1
drivers/acpi/apei/ghes.c:1
drivers/acpi/apei/hest.c:1
drivers/acpi/atomicio.c:3
drivers/acpi/osl.c:1
drivers/acpi/pci_root.c:1
drivers/acpi/processor_perflib.c:2
drivers/acpi/thermal.c:2
drivers/acpi/video.c:3
drivers/acpi/video_detect.c:1
drivers/pci/quirks.c:1
include/linux/printk.h:2В командном зачете чемпион в лице acpi/ очевиден. В индивидуальном в топе энергосбережение на AMD K8.
Без всяких претензий на репрезентативность, чисто любопытства ради.
> Уж лучше пусть в ядре будет полностью драйвер (который можно отлаживать, дебажить
> и исправлять. И опять же, не тебе же это делать?), чем
> набор (большой набор, для каждой модели материнки, ноута) костылей-воркэраундов, в которых
> комменты в стиле "хрен его знает зачем, но этот ноут работает
> только вот с этим магик-значением".Чтобы этих комментариев не было, код в наше с вами ядро должны производители сабмиттить... Да и то не гарантия.
> Чтобы этих комментариев не было, код в наше с вами ядро должны производители сабмиттить... Да и то не гарантия.Чтобы вот ТАКИХ комментариев не было, нужно понимать, что дрова итак дублируются:
> # dmesg | grep -i "native driver"
> [ 3.467731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253719] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253727] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253732] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driverПочему? Да потому что на ACPI итак не полагались. Да и системы без ACPI таки до сих пор есть, в которых эти же девайсы а) вставляются, б) работают и в) APM (Advanced Power Management) BIOS support никто пока из ядра по этой причине выкидывать не собирается.
Это ж не вын8.
> Чтобы вот ТАКИХ комментариев не было, нужно понимать, что дрова итак дублируютсяКак это опровергает сказанное?
> Почему? Да потому что на ACPI итак не полагались.
В х86 десктопах, последние лет 20?
> Да и системы без ACPI таки до сих пор есть, в которых эти же
> девайсы а) вставляются, б) работаютЭти системы используют свободный драйвер от производителя железа? Если нет, то к чему это?
Вот и подумайте «почему»зыж
>> Да и системы без ACPI таки до сих пор есть, в которых эти же девайсы а) вставляются, б) работают
> Эти системы используют свободный драйвер от производителя железа? Если нет, то к чему это?И свободный (как от производителя, так и от сообщества), и проприетарный.
Например:
> # modinfo /lib/modules/3.13.6-gentoo/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko | egrep 'power_save|description'
> description: Intel(R) Wireless WiFi driver for Linux
>parm: power_save:enable WiFi power management (default: disable) (bool)К чему именно ваш вопрос, не понятно.
> Вот и подумайте «почему»Спасибо что не в гугл.
> Например:
>> # modinfo /lib/modules/3.13.6-gentoo/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko | egrep 'power_save|description'
>> description: Intel(R) Wireless WiFi driver for Linux
>>parm: power_save:enable WiFi power management (default: disable) (bool)
> К чему именно ваш вопрос, не понятно.К релевантности "других систем", очевидно. Если они работают на проприетарных компонентах, то какой смысл это упоминать в контексте темы новости. Насчет примера, интеловская firmware закрыта, насколько понимаю. Свободные для других чипов есть, но опять же, что опровергают контрпримеры?
> К релевантности "других систем", очевидно. Если они работают на проприетарных компонентах, то какой смысл это упоминать в контексте темы новости.Видимо именно это и называется — бла-бла-бла.
> Насчет примера, интеловская firmware закрыта, насколько понимаю. Свободные для других чипов есть, но опять же, что опровергают контрпримеры?А драйвера (открытые, о которых вы спрашивали) от фирмваре не отличаем, да?
Наивно полагаем, что этот аналог ппзу с дровами ядра собеседник перепутает?
Зыж
> что опровергают контрпримеры?Ещё раз. Какие контрпримеры?
Давайте, представьте такое оборудование, которое работает только через аспи-дрова.
Я не понял чего вы кипятитесь. Мой начальный пост был к тому, что комментарии типа "тут используем этот непонятный мэджик" неистребимы если код дает не производитель железа (да и то не всегда). Неважно, где и как этот код работает. Как это опровергается (если так) всем последующим не понял, эмоции тем более.
> Я не понял чего вы кипятитесь.Ни в одном глазу. :D
> Мой начальный пост был к тому, что комментарии типа "тут используем этот непонятный мэджик" неистребимы если код дает не производитель железа.А сейчас их 2-а.
Один для нативного (при чём от вендора. Времена плохой поддержки прошли. Загляните в код. Даже если нет поддержки какого-нибудь сидюка, по факту все они на базе 3-4 чипсетов, производители которых есть в не только в ядре но и в ЛФС. Из последних мастодаев разве что невидиа. За что ей Линус уже..), второй для аспи, который не от вендора, а от производителя конкретной железки (с анб или без, х/з).Ну и ваш "контрпример" всё ещё не в студии.
Зыж
> Неважно, где и как этот код работает.Да что вы говорите? :D
Важно. И очень. Но это уже отдельная тема.
> А сейчас их 2-а.
> Один для нативного (при чём от вендора. Времена плохой поддержки прошли.Да, того, что было лет 15 назад, нет. А так, может где-то и есть два варианта, оба свободные, рабочие и читабельные, а где-то подобное еще не завтра закончится:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971061
http://marc.info/?l=linux-acpi&m=139359680828880&w=2/
> Ну и ваш "контрпример" всё ещё не в студии.
Там ваши имелись в виду. Про железяки без ACPI или с нормальными драйверами.
> Зыж
>> Неважно, где и как этот код работает.
> Да что вы говорите? :D
> Важно. И очень. Но это уже отдельная тема.Говорю. В смысле наличия мэджиков нет разницы, FW это или кусок ядра, например. И там, и там водятся.
> Говорю. В смысле наличия мэджиков нет разницы, FW это или кусок ядра, напримерГоворю же — 2-а.
Дрова отдельно, аспи отдельно.
При этом версия(состав,..) аспи зависит от производителя железки, а не чипа.Зыж
И юлить не нужно, пример плс.
Остыньте.
это вам такой совет нужно давать.
и изучать мат.часть.
Обязательно.
Вот и ладушки.
>> Говорю. В смысле наличия мэджиков нет разницы, FW это или кусок ядра, например
> Говорю же - 2-а.
> Дрова отдельно, аспи отдельно.
> При этом версия(состав,..) аспи зависит от производителя железки, а не чипа.
> Зыж
> И юлить не нужно, пример плс.:-) Мнооого. Самое наверно важное - вентиляторы. Потом suspend.
Из менее важного, но тоже важное - спец кнопки (яркость...).
И всё это действует на те самые устройства, по поводу которых '...instead of native driver...'. То есть ACPI их контролирует и выдаёт какие-то команды по ходу выполнения означенных функций. Ответ на вопрос что произойдёт если в дело замешан "native" драйвер ничего не знающий об ACPI и роли устройства в общем-то отсутствует. Ко всему этому конечно могли бы быть свои драйверы, но... :-) В целом видимо нужен был бы драйвер для каждой материнской платы. Специализированный. Вместо этого разработали ACPI. К сожалению, реализаторы усиленно занялись в ACPI нестандартной, далеко идущей поддержкой виндовс, включая преднамеренное вредительство в случае Linux...
> :-) Мнооого. Самое наверно важное - вентиляторы.В дровах.
Не в аспи.
Пример — в навье можно отрубить карту, в блобе нвидиа нельзя.
> Потом suspend.Точно не функция, которая зашита в аспи.
Должна дёргать дрова. Хотя бы для сброса дампа на винт.
И да, вы вообще не понимаете о чём речь.Зыж
> Из менее важного, но тоже важное - спец кнопки (яркость...).Да-да, как раз мой патч для пары ноутов в ядре и засветился. :D
Не, ну вы точно не знаете о чём идёт речь.
>[оверквотинг удален]
> Пример - в навье можно отрубить карту, в блобе нвидиа нельзя.
>> Потом suspend.
> Точно не функция, которая зашита в аспи.
> Должна дёргать дрова. Хотя бы для сброса дампа на винт.
> И да, вы вообще не понимаете о чём речь.
> Зыж
>> Из менее важного, но тоже важное - спец кнопки (яркость...).
> Да-да, как раз мой патч для пары ноутов в ядре и засветился.
> :D
> Не, ну вы точно не знаете о чём идёт речь.Сознаюсь, после этого уже не знаю о чём у вас речь.
suspend на винт ничего в общем-то вроде дампа не сбрасывает. Это не hibernation. (но это так, из фрагментарно понятного).
Кнопки управления вряд ли работают через ваш патч...
Ну и чтобы вам тоже не казалось, что вы понимаете о чём речь, она в том числе о native драйверах такого странного устройства от intel, как Communication controller 8086:1e3a ... Не wifi, ни ethernet, а Communication Controller... :-)
А что тут не понятного?
> # dmesg | grep -i "native driver"
> [ 3.467731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driverЕсть ACPI-драйвер (в биос'е), есть нативный (в ядре, в модуле ядра).
Все примеры, что вы привели, из разряда последних.
В том числе кнопки. Мой ли там патч или ещё чей-то.
И да, поначалу я таблицы аспи правил и компилил интеловским компилятором, потом просто добавил в ядро, как все делают.
И ещё, в ACPI буква P означает power. Поэтому речь шла о драйверах по управлению питанием различных устройств. Т.е. кнопки тут вообще ни при чём. И обрабатываются эти события в любом случае ядром.Зыж
> ACPI driver is available for this device, you should use it instead of the native driverВот из-за этого "use it instead" бэклайт (опять же, power!!!) и не работал.
Потому что мс в вын8 стала использовать именно натив-драйвер для этих целей, про аспи-дрова все забыли (и забили) и они в линухе (и не только в линухе) работали криво.
> А что тут не понятного?
>> # dmesg | grep -i "native driver"
>> [ 3.467731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> Есть ACPI-драйвер (в биос'е), есть нативный (в ядре, в модуле ядра).
> Все примеры, что вы привели, из разряда последних.Ага... Только не кажется ли вам странным, что драйвер ядра, к примеру, к вентилятору находится в подсистеме ACPI? :-)
ACPI не предусматривает драйверов в BIOS... (Хотя чего только не бывает в мире windows...) :-)
Вот драйвер вентилятора, который в подсистеме ACPI, - это тот самый ACPI драйвер, который надо использовать "instead of". Соответствующий "нативный" драйвер может управлять каким-нибудь контроллером, но... Связь этого контроллера с собственно вентилятором вещь туманная. Так что он просто так не закрутится. Это когда вообще драйвер контроллера есть.
Хотя метод так сказать тыка может и помочь...
Любопытно, что имеются системы, где вентилятор управляется даже без участия этого драйвера ядра. И есть системы, где это зависит от того, как себя идентифицирует OS. Скажем в win 7 он управляется без участия ОС, в XP по командам OS... :-)> Зыж
>> ACPI driver is available for this device, you should use it instead of the native driver
> Вот из-за этого "use it instead" бэклайт (опять же, power!!!) и не
> работал.
> Потому что мс в вын8 стала использовать именно натив-драйвер для этих целей,
> про аспи-дрова все забыли (и забили) и они в линухе (и
> не только в линухе) работали криво.Неужели не работал backlight? Что-то я сомневаюсь что это из-за ACPI драйвера. Разве только из-за его отключения :-)
Хотя методы управления backlight и вообще видео платами отличались (и отличаются) разнообразием багов...
> Ага... Только не кажется ли вам странным, что драйвер ядра, к примеру, к вентилятору находится в подсистеме ACPI? :-)Не кажется.
Про ворэроунды уже говорил.
А вот про поверконтрол (и связанные с этим вентиляторы) вы как-то забыли.
А ведь тут, на опеннете, уже не раз рапортовали о 20%/30%/... увеличении производительности амд-шных (да и навью) дров, после включения поддержки этого самого повер в (внимание!) дрова.Зыж
Всё остальное — толи попытки неуклюжего троллинга, толи нежелание (или отсутствие возможности?) признавать свои ошибки, толи и то, и другое.Ззыж
> И есть системы, где это зависит от того, как себя идентифицирует OS. Скажем в win 7 он управляется без участия ОС, в XP по командам OS... :-)А вы пробовали ставить вантуз на голый ноут?
Трах по полной программе. При том что аспи-таблицы для вантуза хотя бы проверяются вендором.
В общем, ни о чём. Вам с клоуном надо в дуэте выступать.
> От аспи даже мс в вын8 отказалась.ну тут я погорячился (а то от троллей ссаными тряпками не отмашешься), но на многие девайсы вын8 перестала полагаться на аспи
А как же Вынь8 без ACPI живет?
а вот и первый из упомянутых в #16 ☺зыж
вот пруф https://lkml.org/lkml/2013/7/17/718
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest
> thing to do would be to just disable ACPI backlight control entirely if the
> firmware indicates Windows 8 supportперевожу, подсветкой управляет устанавливаемый драйвер, а не ACPI.
поэтому многие призводители вообще забили на проверку работоспособности ACPI по управлению backlight.
ззыж
бесусловно ACPI, UEFI SecureBoot, etc — всё это работает на руку мс.
но и им надоедает порой бороться с багами этих зондов.
На acpi, то они забили, что приведет к неработоспособности управления подсветкой в лине. А вот сделать альтернативный интерфейс под линь тоже они забыли. И вряд ли вспомнят несмотря на крики Шатлворда. Будут отбрехиваться как обычно: мы поддерживаем только виндавс, устройство поставдяется с виндавс, от-итесь.
Что за чушь вы пишите. Аспи итак не работал до конца толком.
В ядре итак куча воркэраундов созданных методом тыка и такой-то матери.
(В дополнение(!!!) к ядерным же дровам)Зыж
> На acpi, то они забили, что приведет к неработоспособности управления подсветкой в лине.С чего вдруг?
Просто линух-ядро полагалось на аспи, которая бодро рапортавало, что она всё это поддерживает и работает.
А то что оно работает криво и что из-за смены подхода в мс вын8 на это все забили и не тестировали, это оно не говорит.
Поэтому выключаем аспи-дрова, включаем ядерные и всё начинает работать.
ззззззыж
>(В дополнение(!!!) к ядерным же дровам)чтобы не быть голословным:
> # dmesg | grep -i "native driver"
> [ 3.467731] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253719] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253727] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> [ 6.253732] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver.
> На acpi, то они забили, что приведет к неработоспособности управления подсветкой в
> лине. А вот сделать альтернативный интерфейс под линь тоже они забыли.
> И вряд ли вспомнят несмотря на крики Шатлворда. Будут отбрехиваться как
> обычно: мы поддерживаем только виндавс, устройство поставдяется с виндавс, от-итесь.Ну, зато Шатлворд пропиарится, уже хорошее дело.
> На acpi, то они забили, что приведет к неработоспособности управления подсветкой в
> лине. А вот сделать альтернативный интерфейс под линь тоже они забыли.
> И вряд ли вспомнят несмотря на крики Шатлворда. Будут отбрехиваться как
> обычно: мы поддерживаем только виндавс, устройство поставдяется с виндавс, от-итесь.Не забыли :-) Когда есть в наличии графический драйвер, то... Там бывает и управление подсветкой.
Но вообще выход Wndows 8 никак не отменяет спецификаций ACPI. И баговость win 8 может пополниться ещё одним набором.
А вообще, с управлением подсветкой там много багов и "нестандартных решений".
Начиная со специально приспособленного к виндовс WMI (Windows Management Instrumentation), совершенно ни для чего более не нужного и не стандартизированного.
> Ну всё-таки сама идея прятать код под стандартный API весьма здравая и
> тянуть в ядро ещё кучу кода под разные мамки -- гиблое дело.Ну так не сам же Марк будет это делать. Для этого есть негры из редхата, на котрых можно свалить всю грязную работу и все вылезшие проблемы. А самому остаться Дартаньяном на белом коне, и скушать все сливки.
> тянуть в ядро ещё кучу кода под разные мамки -- гиблое дело.А таки тянут. Уж как минимум под конкретные чипсеты и прочая. Ядро в основном программирует оборудование напрямую. Что к лучшему. Полагаться на глюкавые проприетарные BIOS и прочие UEFI'анства - удовольствие ниже среднего.
Ага, счас, так его и послушали. Авторитет уже и так ниже плинтуса.
> Авторитет уже и так ниже плинтусаСреди анонимных аналитиков?
Шаттлворта хотя бы не только сектанты слушают, но и производители.
> Шаттлворта хотя бы не только сектанты слушают, но и производители.Пока что, при заключении контрактов на убунту с производителями, диктуют условия именно вендоры. Это ж не мелкософт какой-нибудь, чтобы указывать им, что делать.
> Среди анонимных аналитиков?Да даже среди его приверженцев, не говоря уже об остальных. Upstart слил, Mir, судя по новостям, уже в процессе слива, вместе с новой Unity.
> Шаттлворта хотя бы не только сектанты слушают, но и производители.
Чтобы производители послушали, нужно не _призывать_, а _требовать_. Но для этого у него кишка тонковата.
> Да даже среди его приверженцев, не говоря уже об остальных. Upstart слил,Это хомяки на форумах вещают что слил. А на самом деле он делал сам, пока нужного не было. А как появилось - сбагрил затраты по разработке на других. Бизнесмены - они сообразительные, в отличие от хомяков. Пока хомяки меряются у кого длиннее с микрометром, этот гражданин бизнес делает. Поэтому у него - миллионы, а у вас - фига в кармане.
Удобная отмазка, если бы не одно но: громогласные заявления что "уж мы - то Д'Артаньяны" насчёт мира, апстарта и убунтофона. Тогда получается, что шатловорот не просчитывает ситуацию даже на ход вперёд? Выходит не просчитывает и делает хорошую мину при очередном окунании в лужу.И "миллионы" он заработал единожды, удачно продав verisign во время бума доткомов, с тех пор только тратит. Убунта за 8 лет - всё ещё убыточна. Из монетизации - вышел пшик, несмотря на хомячков (ubuntu one, линзы).
На подходе очередной факап с убунтофоном, потому что в разработку он вложился по полной, а вот продать - пока никому не получается.
> Удобная отмазка, если бы не одно но: громогласные заявления что "уж мы
> - то Д'Артаньяны" насчёт мира, апстарта и убунтофона.И что характерно, у шатлворта будет и система инициализации как ему хотелось, и убунтофоны, и что там еще. А какие именно там будут внутренности - с точки зрения ведения бизнеса не настолько уж и принципиально. К тому же, черный пиар - тоже пиар :).
Остальную часть сообщения предпочёл не заметить, да?> как ему хотелось
хрена с два ему так хотелось, убунтоид.
Ну так он как раз и набивает себе авторитет, кося под Столмана.Вендорам, конечно, пофиг, а вот юзеры запомнят, что Марк хороший и неустанно заботится о них, лично защищая от троянов в биосе.
И эта, пристрелите, пожалуйста, микрософтный компилятор dsdt!
Молодец Марк, набирает себе авторитет.
> Марк предлагает производителям перейти к практике применения пассивных прошивок, которые предоставляют данные об организации взаимодействия с оборудованием и описывают зависимости, но не включают в себя исполняемый код. Код для управления оборудованием при этом предлагается интегрировать непосредственно в ядро операционной системы, без обращения к прослойкам, таким как ACPI.Так уже есть, Device Tree называется. Производители именно за то и любят ACPI, что он позволяет вынести Power Management из ядра. Вот что пишет об этом Grant Likely (отсюда: http://www.secretlab.ca/archives/27#Why_UEFI_and_ACPI? ):
Hardware and silicon vendors look at ACPI in a very different way than kernel engineers. To begin with they already have hardware and process built around ACPI descriptions. Platform management tools are integrated with ACPI and they want to use the same technology between their x86 and ARM product offerings. They also go to great lengths to ensure that existing OS releases will boot on their hardware without patches to the kernel. Using ACPI allows them limited control over low level details of the platform so that they can abstract away differences between systems.
> Производители именно за то и любят ACPI, что он позволяет вынести Power Management из ядра.производители чего? Софта? Угу, оно и видно как они его любят https://lkml.org/lkml/2013/7/17/718
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest
> thing to do would be to just disable ACPI backlight control entirely if the
> firmware indicates Windows 8 supportзыж
А что такое backlight с точки зрения управления питанием?
Для планшетов/смартфонов (смотрим в свой андроид) "аккумулятор" -> "экран" — 78%.
Таким образом, отказавшись от убравления backlight'ом через acpi, мс сделало этой acpi (смотрим как акроним расшифровывается) нинyжнoй на 78%. Да, на интел-платформе это будет по-меньше, но не особо.
Если вы не понимаете по английски, я переведу: "Hardware and silicon vendors" -- это производители железа, т.е. НЕ софта. Прочитайте внимательно цитату Гранта Лайкли, которую я привел. А лучше всю его статью, я ссылку выше привел.Я всеми руками за Device Tree и за PM в ядре (не потому, что это архитектурно лучше, а потому что только так можно сделать этот код открытым, что в данном случае означает "поддерживаемым", в отличие от ACPI, где глюк на глюке и пофиксить это не представляется возможным). Но нужно понимать, что для ARMv8 например, как минимум для серверных платформ, будет ACPI и UEFI, это требование ARM. В общем, я считаю Грант Лайкли в своей статье очень хорошо всё расписал. Для тех, кто не в теме: он один из главных идеологов и разработчиков FDT, так что знает, о чем говорит.
> Если вы не понимаете по английски, я переведу: "Hardware and silicon vendors" -- это производители железа, т.е. НЕ софта.Проблема в том, что на них всем нас рать. Мс уж точно.
Вот поменяли они стратегию на бэклайт и будут (будут-будут) железячники делать это в дровах, никуда не денуться.
Другое дело что мс полностью тоже не откажется от такой палки в колёсах конкурентов.
С армом таже хрень, что не вендор, то маленький наполеон-мс.
Но сейчас уже попустило слегка — вони много, профита мало. Чуть ли не все вон рута давать стали. Ну и Сноудену спасибо (анб занято, не до закручивания гаек пока).
> С армом таже хреньВы так и не прочли статью по моей ссылке. Абсолютно без разницы, кто будет делать софт для ARMv8, но как минимум все сервера на ARMv8 будут на UEFI+ACPI. И это именно потому, что ARM этого требует. Не то чтобы ARM делал железо, но ARM это и не софтварный вендор. Ну нету на ARM архитектуре МС (то что есть можно не принимать во внимание), тут Linux рулит, ну на мобилках еще iOS есть. Так что...
Цитата из той статьи:
The short answer is, “UEFI and ACPI should be used because ARM’s server specifications will require it.”
Но конечно же это касается только серверов. Но это вполне реальный пример того, что с армом всё не совсем так.
Ну и вспомним конечно про "cute embedded nonsense hacks". Отражает тенденции тех, кого вы называете "софтварными вендорами".
> Вы так и не прочли статью по моей ссылке. Абсолютно без разницы, кто будет делать софт для ARMv8, но как минимум все сервера на ARMv8 будут на UEFI+ACPI.Ну плохо, что.
Так им интел не свалить.
Часть рынка отхапают в любом случае. Но мне, как инженеру, конечно же не нравится ни UEFI, ни ACPI. Единственный плюс -- это то, что они стандартизованы. Минусов очень много: overengineered (что UEFI, что ACPI), ACPI как правило поставляется закрытым блобом, UEFI тот вообще -- от кода ослепнуть можно. Короче жирные гадины. Ну и жесткий стандарт лишает гибкости. Device Tree и u-boot мне намного больше по нраву. Да мне даже board-файлы больше нравились чем ACPI. Но тут же как... Партия сказала -- делаем.
Это рекламная болтовня...По факту было нужно управлять электропитанием и придумали APM - управление питанием через прерывания BIOS. С появлением 32-разрядных ОС появился BIOS32, хотя им мало кто пользовался. При этом появились десятки разнообразных таблиц и подтаблиц с информацией о процессорах, оперативной памяти, установленных устройствах, и т.д. Перед ACPI поставили задачу объединить всё это барахло + добавить псевдокод управления электропитанием (типа: "чтобы выключить: получите байт из порта 10, прибавьте 1, отправьте в порт 11"). Получилось монструозно, сложночитаемо, сложнопарсируемо и глупо (десятки таблиц о разном), зато в одном месте и хоть какой-то "стандарт".
Производители частенько ошибались в псевдокоде и не включали в список устройств устройства, которые по факту были установлены. Поэтому большинство ОС включает в свой состав файлики правильных ACPI файлов для разных материнок.
> Это рекламная болтовня...Эксперты от майкрософта в треде. Крутой гуру, как обычно, спамит. Ну и что что бред, зато подлизнул своим патронам.
you made my day! рекламная болтовня от Гранта Лайкли, everybody! ну хоть широко известный в узких кругах "клоун стаканчик" расставил всё по местам. А то вечно набегут рекламисты типа Торвальдса, Хартмана, Рассела Кинга и прочих, и как давай рекламить! Одно спасение -- тролль-боты от мс, честное слово!
Вот тут Марк молодец! Еще можно upower покритиковать за idevices
Покритиковать - много ума не надо. Вот патч прислать - да.
Об этом нужно почаще говорить просто таким людям. А патч пришли ты, ведь твои призывы вендорам неинтересны
> Об этом нужно почаще говорить просто таким людям.Главное - чтобы только говорили. Потому что если от слов перейдут к делу - хана линуксу.
Маркетолухи не могут в патчи.
> Вот тут Марк молодец!Ну как молодец. Просто пытается саботировать работу Linaro по стандартизации SBSA, полность слив Linux на ARM-системах. Зачем - непонятно.
Неужели у него от успехов линукса так свербит?
>> Неужели у него от успехов линукса так свербит?
> Уебантуфон же продовать как-то надо!Забавно смотреть, как человек старательно пилит сук, на котором сидит. Уничтожит линукс - кто ему ядро писать будет? Маркетолухи?
> слив Linux на ARM-системах. Зачем - непонятно.Затем что очередной UEFI "но на ARM" - вот уж спасибочки.
Интересно, как отреагировали ведущие ядерные разработчики
https://plus.google.com/+OlofJohansson/posts/PnYVv3Mw7mD
https://plus.google.com/+JonMasters/posts/6aVnfMnTMu2Если кратко, Марк призывает похоронить существующие в настоящее время наработки по ARM SBSA, стоившие довольно нехилого труда разработчиков линукса.
Такой себе засланный элопчок.
> Если кратко, Марк призывает похоронить существующие в настоящее время наработки по ARM
> SBSA, стоившие довольно нехилого труда разработчиков линукса.Не очень понятно откуда такие краткости. По первому линку какой-то булшит про ACPI и AML, которые должны сдохнуть жестокой смертью. Вторая ссылка вообще трололо какое-то. Нафиг с пляжу с такой "аргументацией". Еще не хватало загадить еще и ARM левой блоборасией типа UEFI. Тогда точно openrisc всем пи...ц устроит :).
Марк сам же шпионский поиск зондировал в Unity
> Марк сам же шпионский поиск зондировал в UnityКогда шпионим МЫ - ничего плохого в этом нет.
Когда шпионят ОНИ - это возмутительно и недопустимо.
Ни кто этого делать не будет, по тем же самым причинам почему Марк хочет это делать. Производитель производит, потребитель потребляет, это отношения по принципу не нравится не потребляй, вот и все.
Никто пишется слитно.Зыж
Не грамарнаци и не крючкотвор, но... должен быть предел.
> Не грамарнаци и не крючкотвор, но... должен быть предел.P.S. Аноним пишется через "О"
Это "ник", имя нарицательное, двоечник.
Сопствинное жы.
> Ни кто этого делать не будет,У Шатлворта довольно приличная доля рынка серверов нынче, так что сpaться с ним удовольствие дорогое. В смысле, не будет поддерживать ARM с вон той фигней - и ARMовские производители серьезно недопродадут железяк. А такой аргумент любому капиталисту понятен.
> У Шатлворта довольно приличная доля рынка серверов нынче,В голос. Половина от этой "доли" - компы из десктопных компонентов с файлопомойкой или типовые роутеры с проксёй из наработок дебиана.
Для серверного рынка он не делает **ничего** из реально полезного. Вся поддержка железа, юзерспейс части drbd/iscsi/fs - или деяние редхата или самостоятельные проекты.
Большая часть из тех кто выбирал убунту для инфраструктуры - в скором времени или начинала пилить форк или сваливала на что-либо. Из недавних примеров - Мюнхен, Valve и гугл.
> В голос. Половина от этой "доли" - компы из десктопных компонентов с файлопомойкойИ, конечно, мсье приведет нам источник статистики? Могу видный контрпример: википедики всю планету обслуживают. Это вам не ваш локалхост, это отгрузка данных всей планете, на секундочку.
> или типовые роутеры с проксёй из наработок дебиана.
У дебиана цикл релизов непредсказуемый, что делает его не очень удобным в ряде случаев. А в убунте можно еще и выбирать между стабильной некромансией и авангардизмом на свой зад. Т.к. случаи бывают разные - компилять половину софта на серваки самолично может и задолбать, особенно если причина - "в стабильном дебиане вместо софта окаменевшее гомно мамонта".
> Для серверного рынка он не делает **ничего** из реально полезного.
Он операционку делает. Достаточно востребованную.
> Вся поддержка железа, юзерспейс части drbd/iscsi/fs - или деяние
> редхата или самостоятельные проекты.Меня такие кадры прикалывают.
- Если шатлворт ничего не делает - "аа, тунeядец!!!"
- Если шатлворт и ко пиишут код - "ааа!!! захватчики!!! Они хотят всем указывать!!!"Поскольку угодить на вас невозможно чисто технически - безопаснее всего просто показать вам фак. И идите лесом с интересом.
> Большая часть из тех кто выбирал убунту для инфраструктуры - в скором
> времени или начинала пилить форк или сваливала на что-либо.И что там отфоркала википедия, например? Или куда она свалила? А что до форков - так наивно ожидать что под всякие кастомные задачи типа "я тут хочу игровую приставку!" хорошо подойдет какой-то готовый дистр для писюков.
> И, конечно, мсье приведет нам источник статистики?Собственные глаза и долгий опыт работы "пожарным" админом. Т.е. я исправляю то, что наворотили убунтоиды.
> Могу видный контрпример: википедики всю планету обслуживают. Это вам не ваш локалхост, это отгрузка данных всей планете, на секундочку.
Читал, что им миграция встанет дороже, только поэтому они до сих пор на убунте.
> У дебиана цикл релизов непредсказуемый
>ЩИТО?! Да ты наркоман. Предсказуемо стабильный релиз раз в 2 года +/- месяц. https://wiki.debian.org/ru/DebianReleases
С другой стороны - убунта "гонит план". Пофиг, что релиз эпичное глюкалово, зато вовремя.> А в убунте можно еще и выбирать между стабильной некромансией и авангардизмом
Поправка: ТОЛЬКО между стабильной некромансией и лютым авангардизмом. LTS протухает очень быстро и зависит от обновлений дебиана, "обычные" релизы следующие 2 месяца после выхода (из 6х месяцев жизни) патчатся на треть объёма и к серьёзному использованию не пригодны.
А если ещё навтыкать ppa, будет не обновление, а праздник жизни.>> Вся поддержка железа, юзерспейс части drbd/iscsi/fs - или деяние
>> редхата или самостоятельные проекты.
> Он операционку делает. Достаточно востребованную.Ага, делает:
http://www.opennet.me/opennews/art.shtml?num=37926 // поддержка оборудования
http://blogs.gnome.org/bolsh/2010/07/28/gnome-census/ // база для юнити
http://www.konqueror.org/developers/ // DE, отличное от юнити> под всякие кастомные задачи
...так и запишем, "настраиваемость отсутствует".
> какой-то готовый дистр для писюков.
типа винды, ага.
> Поскольку угодить на вас невозможно чисто технически - безопаснее всего просто показать вам фак.
Слив защитан.
> Код для управления оборудованием при этом предлагается интегрировать непосредственно в ядро операционной системы, без обращения к прослойкам, таким как ACPIИ да здравствуют материнские платы с огороженным проприетарным драйвером для windows без поддержки других ОС. Мы это с модемами в своё время уже проходили.
лол.
учитывая что исторически финансовый бэкэнд, Марк - имеет общий и с фоксконном и ко и с майкрософт - выглядит довольно надутыми щОки, в таком PR-е =)
>финансовый бэкэнд, Марк - имеет общий и с фоксконном и ко и с майкрософт - выглядит довольно надутыми щОки, в таком PR-е =)Ради _доли_ в трафике с б.е. можно и шчёчки понадувать. Это же и есть пэ-рэ.
Господи! Спасибо! Хоть Шаттлворт педали сгрёб до кучи!
>педали сгрёб до кучи!Неместные, геть отседова.
одобрямс