Vlákno názorů k článku
V jádře se diskutuje podpora priority při vypnutí
od RDa - Zajimave remcaj.. ale ze existuje CONFIG_ACPI_CUSTOM_DSDT_FILE si uz...
-
DannyStříbrný podporovatelA co teprve takove device tree (dts)... :-) A take kolem toho byly dlouhe diskuze.
-
Tak jako vzdy je pro i proti.
Mohli jsme mit poradek na ARM deskach, kdyby se tam ujal UEFI BIOS (je na velice malo zarizenich), ale bohuzel cena komponenty pro ulozeni biosu ktery se pusti jen jednou po zapnuti je prilis vysoka - takze se namisto toho mrhaji prostredky celeho sveta :D
a naopak to funguje taky - PC nepotrebuje vlastne BIOS, i x86 by mohlo fungovat na device tree bazi, a taky ze vznikaji takove reseni - coreboot a spol. A jede to naramne rychle (zkusnost mam jen z x86 chromebooku)
-
Mně tedy pro embedded více vyhovuje flexibilní low-level konfigurace přes device tree (které si navíc mohu přiohnout úpravou zdrojáku driveru, příp. ubootu, když driver potřebné nastavení z DTS nečte) + sériová konzole, než být omezený možnostmi closed-source biosu, které si zrovna výrobce usmyslel naprogramovat. Samozřejmě pokud by to bylo také open source, pak by to možná bylo jedno. Ale klikací omalovánky GUI UEFI mi na armu nijak nechybí...
-
UEFI nemusi mit gui - nejde o konfiguraci. Jde o to, ze "device discovery" API poskytuje UEFI primo nebo skrze ACPI (treba mapu pameti a PnP zarizeni).
V dnesni dobe je DT spis opruz na nekterych platformach, protoze existuje jedno DT pro uboot, ktery je bez nej casto ztracenej, a pak druhe DT je to co user (vy) chcete, ale muze to byt v nekonzistenci s tim co si uboot vytvorilo.. a nakonec pak tam vstupuje do hry dynamicke patchovani DT ubootem.. no nebylo by lepsi mit klasike "bios" API nez takoveho kockopsa? :D
-
Pokud budou v biosu všechny možnosti/kombinace daného HW, je mi to jedno. Ale nevěřím, že to výrobce nezflikuje, jako všechny biosy. Ale pokud by to bylo open source a snadno to šlo přehrát novou verzí (jako uboot/kernel/dts), je mi to celkem jedno. Navíc nevím, jak by se to v biosu nastavovalo bez GUI - tedy opět nějaký txt formát..... dts....
-
DannyStříbrný podporovatel
Tak ono to tady "textove" je taky jen ve zdrojaku. Jinak pri bootu se pracuje s verzi, co uplne easy-peasy citelna neni... :) A samozrejme v te kernelove source-strukture je to pomerne slusne utopene...
Ale v obecne rovine souhlas - ono to co je k videni "v HW" je obcas bida - a dost casto se vyrobce ani k oprave nema. Ostatne kernel je plny quirku, kterymi se ruzne tezko zmenitelne chyby obchazi. A samostatnou kapitolou jsou ruzne errata - kdy vyrobce HW proste oznami, ze neco je "jinak" - a poper se s tim v SW jak chces :-) A ze treba u tech armu jich je...
-
Přesně. Zajímalo by mě ostatně, jestli někomu dochází, že absence rozumného BIOSu ARM svět docela solidně brzdí. Já osobně bych si třeba milerád pořídil nějaký ARMový SoC a používal ho jako desktop. Jenomže od desktopu čekám, že přijdu, z flešky nainstaluju standardní systém ze standardní distribuce (jen nikoliv amd64 ale armXYZ) a nebudu nic dalšího řešit.
I tohle je jedna z věcí, proč je to teď na dvě věci.
-
Jenže obecný image není optimalizovaný:
64-bit ARM Linux Kernel Against CPU-Specific Optimizations: "Pretty Unmaintainable"
https://www.phoronix.com/news/ARM64-Linux-No-Uarch-Opts -
Jenomze takova optimalizace nefunguje ani v x86 svete - proste bud mate nejake generice jadro (x86-64), anebo mate Gentoo a jedete si svoje -march/-mtune stejne jako na embedded armove krabicce.
A stejne tak neexistuje optimalizovany userspace - bud ho mate pro Haswell+ (s AVX2), anebo nejaky basic 64-bit target, ktery bezi vsude ale optimalni nebude.
Bohuzel dnesni cpu HW se iteruje prilis rychle a prinasi mno malych a castych zmen.. a to neprospiva pak tomu, kdo by to chtel mit top top. A neni to dostatecne rozbity, aby se oplatilo delat dynamicky nacitane binarky podle cpu (zde ma Apple ponekud navrch, kdyz v binarkach udelal koexistenci vicero architektur - to by za cenu 4-5x prostoru bylo mozne pouzit pro vsude-optimalni distro).
-
Asi tezko, kdyz nabootuji instalaci na usb mediu ve starsim kompu, tak kernel nabehne ale jak zacne init poustet sluzby tak to strili jeden invalid op za druhym... takze o dynamicky optimalizovanem kodu rikejte pohadky nekomu jinemu.
To ze urcite aplikace si delaji aplikacni detekci cpuflags a podle toho pouzivaji rutiny (napr. mplayer) je neco jineho nez bych chtel a mel jsem na mysli v predchozim prispevku.
-
hlavně ty problémy ani neřeší. Problém je, že se zařízení vypne rychleji než stačí udělat svoji práci (jak jsem pochopil z vlákna) a navrhované řešení je změnit pořadí v jakém se zařízení vypíná, aby mělo teoreticky možná i víc času (žádný čas se nezaručuje).
Cituji Grega:
But your patch is not guaranteeing anything, it's just doing a "I want
this done before the other devices are handled", that's it. There is no
chance that 100ms is going to be a requirement, or that some other
device type is not going to come along and demand to be ahead of your
device in the list.Takže asi chápu, že dělat tuhle relativně zasahující změnu jen proto, aby to možná fungovalo je divné.
-
Což ale je argument na úrovni "scheduler nezaručuje, kdy procesu přidělí quantum, proto je zbytečné s výjímkou RT kernelu preemptivní scheduling", nebo celé (K)ASLR, kanárci na stacku, emergency sync a remount na R/O při chybě bloku etc.
Ostatně pak by byl zbytečnej i nějakej ten upsd co dělá systém shutdown při battery low, protože není záruka že shutdown projde včas, že ano.
Ano, problém to neřeší, ale to neřeší 99% kódu kernelu, a ani to nebyl požadavek. Požadavek byl na best effort na omezení vzniklých problémů, a to diskutované návrhy splňují.
28. 11. 2023, 15:42 editováno autorem komentáře
-
V pripade aktualniho patche pro prioritizovani eMMC se nejedna o zadny graceful shutdown operacniho systemu a userspace, ale to, ze az prijde signal ze pada napeti, tak se do emmc posle neco jako "Na vsechno se okamzite vys*r a schovej se!". Zadnej sync, natoz umount/remount na ro. Protoze je lepsi kdyz cip nedela nic kdyz dojde stava, nez aby neco delal a u toho pomalu chcipal.
Onehda byl jeden krasnej bug v Xilinx FPGA, kdy padajici napeti zajistilo prepsani eFuses a tim se preprogramoval sifrovaci klic na random hodnotu.. to fakt chces. Ale tam bylo vydano jako reseni ze se ma pridat hw supervisor, co cip podrzi v resetu v tech stavech kdy napeti neni stabilni:
