Názory k článku
V jádře se diskutuje podpora priority při vypnutí

Hodně zajímavá debata a velice poučná, jak civilizovaně argumentovat a snažit se najít kompromis. Díky za link!

Až tak v půlce čtení mi došlo, jak to myslíte :-D

Diskuze v LKML pomalu na úrovni Novinky.cz

Myslel jsem to zcela vážně, "novinky" z toho spíše dělá zvolený výcuc ve zprávičce.

Je tam vidět, že to měl navrhovatel předjednané s Markem Brownem (správce např. ALSA SoC, takže embedded svět), který návrh podpořil. Na druhé straně Greg správně brání kernel před "zbytným" balastem, tlačí maximum do user spacu, ale nechává si důvody vysvětlit. Vývojáři musí argumentovat a hledat kompromis. Čistě technické argumenty, ani náznak čehokoliv osobního. Mně se to líbí.

27. 11. 2023, 18:03 editováno autorem komentáře

Opravdu? Vlákna v LKML pravidelně čtu a je tam obrovský rozdíl v kultivovanosti. Vždyť i tady nejsou žádné osobní urážky, nadávání, osočování, ale naopak snaha o argumentaci a diskuzi.

Zajimave remcaj.. ale ze existuje CONFIG_ACPI_CUS­TOM_DSDT_FILE si uz nepamatuji? Tolik k tomu, zda ma SW resit problemy nedokonaleho HW (a to prosim u biosu lze alespon flashnout novou verzi.. na rozdil od fyzickeho zapojeni obvodu nebo designu chipu).

A 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

Pro embedded možná. Jenomže pro neembedded je to jedna z docela solidních gotchas. A že by se při dnešních výkonech armových SoC využití našlo snadno.

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

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é.

Má pravdu. Ale druhá strana má také pravdu - lepší výrazně snížit pravděpodobnost poškození eMMC než nic. Navíc dle slov navrhovatele se tato prioritizace již dlouho v automotive používá out-of-tree s dobrými výsledky.

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:

https://support.xilinx.com/s/article/65240?language=en_US