Vlákno názorů ke zprávičce Některé nové notebooky od Samsungu nepřežijí instalaci Linuxu od failer - Pravděpodobná příčina a řešení: http://www.jakobheinemann.de/en/blog.html První soud pro z...
-
failer (neregistrovaný)
Pravděpodobná příčina a řešení: http://www.jakobheinemann.de/en/blog.html
První soud pro z takovéhoto důvodu zamítnutou reklamaci by Samsung jistě prohrál. -
Lael Ophir (neregistrovaný)
To vypadá spíš na problém se ztrácejícím se BIOS/EFI setup menu. Samsung sice odpoví chybnou na údajně validní dotaz, ale autor v kódu jaksi zapomněl ošetřit chybové stavy. Když nastane chyba, přesto pokračuje v modifikaci, což je velká chyba. Ale samozřejmě s klidem řekne, že za to může Samsung. Na co ošetřovat chyby? :/
-
Lael Ophir (neregistrovaný)
Toho jsem si v linku nevšiml. Zdroj?
Linkovaný článek rozebírá situaci, kdy po instalaci Linuxu na Samsungu nejde vstoupit do BIOS Setupu pomocí F2. U Samsungu EFI volání GetNextVariableName() selže, pokud velikost předaného bufferu není 128 bytů, což je dokumentované v EFI 1.0, ale nemělo by to být třeba u EFI 2.0. Bohužel modul efivars.c definuje délku názvu proměnné i hodnoty jako 1024 (struct efi_variable), což u Samsungu neprojde. Až sem to možná bude chyba Samsungu (pokud je specifikace opravdu jednoznačná). Funkce virt_efi_get_next_variable() z efi.c se chová správně, a vrátí chybu. Bohužel ale instalátor chybu neošetří; přitom by se měl zastavit a nahlásit chybu, pokud dostane cokoliv mimo EFI_SUCCESS (položka načtena) nebo EFI_NOT_FOUND (konec seznamu). Místo toho se instalátor chová, jako kdyby byla tabulka prázdná. Díky tomu pak s klidem přepíše položku zavaděče, která normálně implementuje BIOS Setup.
Takže čí je to vina? Samsung si od Phoenix Technologies koupil EFI Runtime Services, které činí nesprávný předpoklad u nějakého parametru (vychází chybně z EFI 1.0). Nicméně instalátor neošetřuje chyby, a po chybě naprosto nesprávně přebuší tabulku boot entries. Můj verdikt? Mohou za to obě strany, a autor instalátoru výrazně víc.
Co s tím? Takové věci se stávají odjakživa, a lze je vychytat jen při důkladném testování. To bohužel u Linuxu chybí. Při tom množství dister a tempu vydávání nových verzí se testuje špatně. Navíc když za distra uživatelé neplatí, nejsou na to peníze.
-
Mimochodem, toto je nevýhoda řízení chyb návratovou hodnotou. Při použití výjimek by se to mohlo stát jen při nedodržení transakčnosti.
Zastávám názor, že chyba, kterou programátor neošetřil, se mu má buď otlouct o hlavu při kompilaci (řízené výjimky), nebo při běhu ukončit program. Ne pokračovat dál. Podobné problémy mohou být i u setuid/setgid (např. RageAgainstTheCage pro Android).
-
Lael Ophir (neregistrovaný)
Ano, návratovou hodnotu je potřeba vždy ověřovat, ale autoři kódu to mnohdy nedělají, protože je to pakárna. S výjimkami se programuje lépe, a chybu "omlátí o hlavu", místo aby někde v hloubi aplikace vyhnila. Jenže podpora výjimek na straně jazyků není zrovna dokonalá: v C je nulová, a v C++ nebyla podpora povinná. Implementace na straně OS také není úplně triviální, zvlášť pokud chcete API exportovat i pro kód psaný v C. Pak tu samozřejmě byly problémy s výkonem u starších implementací.
Budoucnost je zřejmě jasná. Výjimky najdete ve Win32 (počínaje SEH někdy před 18 lety), v .NETu, Javě, C++/CX, a v podstatě všude jinde. Jenže to jde pomalu. Nakonec na rootu často oslavovaný kernel Linuxu je téměř 1:1 přepis kódu ze začátku osmdesátých let.
RageAgainstTheCage jsem neznal, děkuji za tip.
