devicetree - настоящая база и сила линуха. Есть ли что-то такое у винды?

У винды архитекторы в штате. Так что в любом случае там всё лучше сделано, чем в анархолинуксе.

Жду примеры анархии в линухе.

Графическая подсистема.

Альтернативное мнение: devicetree - кошмар и причина анархии на портативных (и не только) устройствах.

Речь о иксах, или фреймбуфере? С fb все норм.

Почему? Наоборот балдеж, если разобраться.

потому что позволяет собирать устройства из однодневного хлама без какой-либо стандартизации.

А девицеманагер в винде - это не оно? Вроде показывает что к чему подключено

WinCE давно умер. Как я слышал от более продвинутого товарища, в WinMobile взяли идеи ядра NT. И так оно и жило до Windows-RT(?), года до 2018, пока не умерло окончательно, похоронив попутно купленную М$ Nokia c телефонами Lumia. В названиях вёнд могу путаться.

А dtb это вынужденная мера, затачивать дерево устройств под конкретный SoC и девайс на нем. В x86 машинах хоть есть PCI, который все расскажет об устройствах с VID:PID, адресами на шине.

Ну devicetree как раз помог этот отстойник причесать. До этого было совсем печально.

очень классная концепция BSP (Board Support Package)

Которая основывается на том, что исходники открыты. Дальше продолжать?

Скорее всего на тех девайсах где эта винда работает есть ACPI/UEFI

Относительно ARM, насколько я помню, уже давно велись дискуссии насчет введения похожего функционала, но видимо из-за огромного числа производителей и зоопарка устройств сделать это в обозримом будущем не представляется возможным. Так что будем юзать дальше devicetree

А так было бы конечно здорово, скачал один образ какой-нибудь ARM Ubuntu а он взял и запустился на произвольной ARM борде, сам всю периферию нашел и соответствующие драйвера позагружал

Ну как на ПК сегодня

Особенно, когда нужно отключить графическую систему, венда прям «прекрасна».

очень классная концепция BSP (Board Support Package)

Которая основывается на том, что исходники открыты. Дальше продолжать?

Не. У QNX тоже есть BSP, хотя сырцы закрыты.

По теме: да, есть Windows IoT и там тоже есть BSP.

Сама идея тащить драйвера в исходники ядра – лютый трешак.

Во времена i80386, когда сторонних девайсов под писюк было штук сто, из которых половина копировала хардварный API другой половины, это, вероятно, было уместно и круто. Сегодня же это ужас.

dtb - это кривое ублюдочное поделие основанное на идеях OpenFirmware, но от безблагодатности армовой инфраструктуры(а точнее отсутствияаналога ACPI таблиц, в котором это можно было бы сделать единообразно) сделанное в том виде, который есть сейчас. Это, конечно, лучше, чем когда надо было писать целый support file, в котором описывать то же самое, но на си, но и от чего-то хорошего далеко.

machine-файлы тоже ничего, но dts можно в рантайме менять, что дает возможно ремаппить гпио с ADC, на, например, моргание светодиодом

Есть ли там что-то типа devicetree, или BSP концептуально ближе к WinCE (т.е как-бы machine-файлы)?

Там используется ACPI выполняющая функции аналогичные FDT.

Невозможность просто взять универсальный образ ОС и запустить на любой ARM/RISC-V железке. Надо страдать и собирать образ для конкретной железки.

Альтернативное мнение: devicetree U-Boot - кошмар и причина анархии на портативных (и не только) устройствах.

Починил. Сам FDT не так уж и плох если корректно составлен и записан в ROM железа, а не кладётся рядом с ОС. А вот U-Boot – это катастрофа, там зачастую прибито к запуску конкретной ОС на конкретном носителе и чтобы запустить другую ОС или ОС с другого носителя часто бывает необходимо пересобирать U-Boot с другими опциями (а если используется закрытый форк U-Boot, то всё).

Лучше бы наконец перешли на UEFI где есть универсальный независящий от конкретной ОС процесс загрузки и автоматический выбор загрузочного диска.

Да, вспомнил за ACPI, под Win 10 Mobile тож акпи юзают, который видимо порт уефи «эмулирует».

угу. Только без u-boot'a была бы какая-нибудь другая корявая погань. Универсальность линуксов всех развратила :(

Зато там при перезагрузке графической подсистемы (Win-Ctrl-Shift-B) приложения не падают и не теряют данные.
И это куда полезнее чем возможность перезагрузить условные иксы (это тоже полезно) убив все приложения при этом.

Зато там при перезагрузке графической подсистемы (Win-Ctrl-Shift-B) приложения не падают и не теряют данные.

В Linux для этого существуют сессии типа VNC. В таких сессиях ничего не падает при экспериментах с видеокартой.

И потом как часто тебе приходится перезагружать X или видеодрова на Linux? Раз в неделю? Или раз в месяц?

И это куда полезнее чем возможность перезагрузить условные иксы (это тоже полезно) убив все приложения при этом.

Да уж куда еще полезнее, с учетом того, что на высоконагруженных серверах графика венды со временем начинает жутко лагать и сыпаться. Такие вендо сервера вообще нередко приходится ставить на автоперезагрузку по еженочному будильнику, чтобы хотя бы не скурвились до вечера.

Фига тебя порвало в какие-то странные размышления про VNC-сессии и вендо-сервера.

Дожили блин, фанатик-линуксоид пытается доказать что отсутствие фичи это даже преимущество, лол.

Смирись эта фича графического стека винды реально полезная и позволяет сохранить данные.

Фига тебя порвало в какие-то странные размышления про VNC-сессии

Это у тебя они странные, а я использую такие сервера на практике даже на localhost для изоляции приложений внутри виртуалки.

и вендо-сервера.

Ничего отстойнее вендо серверов по надежности не бывает, к сожалению.

Дожили блин, фанатик-линуксоид

В чем это проявляется?

пытается доказать что отсутствие фичи это даже преимущество, лол.

Ну так остутствие вредной фичи конечно преимущество. Непотребление наркотиков, алкоголя, табака, и т.п. - разве это плохо? Нам такие фичи ненужны.

Смирись эта фича графического стека винды реально полезная и позволяет сохранить данные.

Сохранить данные у вендового гамес хомяка? И просрать данные на вендовом сервере? LOL

Речь о том, что такая гавно фича на сервере, - это просто жуткий фейл венды, впрочем их там много.

https://ru.wikipedia.org/wiki/WMI

https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page Windows Management Instrumentation

В чем это проявляется?

И тут Федю понесло:

Ну так остутствие вредной фичи конечно преимущество. Непотребление наркотиков, алкоголя, табака, и т.п. - разве это плохо? Нам такие фичи ненужны.
Сохранить данные у вендового гамес хомяка? И просрать данные на вендовом сервере? LOL
Речь о том, что такая гавно фича на сервере, - это просто жуткий фейл венды, впрочем их там много.

u-boot это следствие безблагодатности, ну а точнее, того, что arm не предоставляет чего-то uefi-подобного, мол не наша забота. От того и зоопарк, только последние годы пытаются uefi притащить до вендоров так, чтобы хотя бы на серверных железяках хоть сколько-то единообразно можно было жить.

А на u-boot всем тоже до известного места, потому что всё в ядре и его задача только память подготовить, да образ положить.

В общем, проще обоссать и сжечь, чем исправлять.

Ну как на ПК сегодня

Только на ПК. Если взять любой SoC с x86 внутри, то там абсолютно такой же бардачище как и на всех остальных архитектурах.

Вообще, конечно, забавно, насколько прочно всякие заблуждения сидят в мозгу у персонажей которые кроме писюков ничего на x86 не видели.

И даже писюк - это ещё то адище, которое без проприетарных блобов даже стартануть не получится в принципе, ибо чтобы проинициализировать контроллер памяти на этой говённой архитектуре за каким-то хреном нужно аццкое тайное колдунство ведомое только особо посвящённым с одобрения чужого дяди. Про всякие ME c PSP вообще молчу. Уж лучше армобардак с dts чем этот звездец.

Глянь девайсы времен геода (который MediaGX), там хорошо было стандартизировано за исключением проприетарных штук типа гребенок на промышленных платах

Да, точно, есть же еще u-boot ! :)

Когда мне приходилось с ним сталкиваться, надо было весь его конфиг прибивать гвоздями в неких .h файлах, но там же уже присутсвовала какая-то подсистема работы с dtb. Точно помню что можно было загрузить dtb и поменять в нем значения командами u-boot’a перед стартом ядра

Возможно сейчас и u-boot может использовать dtb для своей собственной конфигурации но это не точно

Или у u-boot’a был свой собственный dtb отличный от кернельного ?

Так я про ПК и пишу

Логично предположить, что если кто-то занимается выпуском dev boards для x86, то скорее всего это те же самые люди которые производят dev boards для ARM, PPC etc. Тогда трудно ожидать что для x86 кто-то будет заморачиваться и делать все по-другому.

К тому же я думаю, что вся эта тема с ACPI/UEFI врядли интегрируется в устройство каким-нибудь благотворительным фондом по запросу производителя, а скорее всего совсем наоборот, стоит вполне ощутимых денег

И если для ПК mainboard это вполне оправдано, то для трехкопеечного устройства на ARMe это может быть экономически нецелесообразным