Linux se bude probouzet a usínat rychlejí

Mno, tak já mám třeba taky Arch (už asi dva roky) a konkrétně po jednom update mi probouzení fungovat přestalo. Oprava se objevila asi za dva měsíce. Na Archu se tyhle věci dít můžou. Zatím mne naštěstí nepotkal žádný fatál a děje se to zřídka, ale tvářit se, že u rolling tohle nebezpečí nehrozí, je pokrytectví.

No jasně. To já si uvědomuju. Na Ubuntu LTS jsem konečně začínal. Nechci se ale zase jako uživatel Archu tvářit, že je vždycky všechno na Archu oukej (k čemuž mají uživatelé Archu sklony).

Mne to taktiež na Archu ide ako hodinky a hlavne tak ako má... :)

No a pak najdete takové ovladače, jako jsou ovladače ACPI pro Asus, který jednu dobu v DSDT používal BCD. Dnes to řeší velmi „standardně“ (zřejmě podle toho, že ten ovladač je MS certified): zkusí binární čísla, a když selže checksum, tak použije BCD. Jistě je to ale něco úplně jiného, než testování zařízení pomocí dokumentovaných rozhraní :-D

Některá pole jsou v ACPI popsané jako "BCD or binary", což je dost síla. V DSDT by být neměla. Pokud měl ASUS takový bug (zdroj?), a chcete aby váš OS fungoval, tak se s tím prostě musíte poprat. Jinak to dopadne takhle:
http://i.stack.imgur.com/HZgpR.png

BTW samozřejmě to je něco jiného, než testování zařízení pomocí nedokumentovaných rozhraní.

Bugcheck 0xA5 je ACPI_BIOS_ERROR, zbytek jsou parametry specifické pro daný bugcheck. Popis je na MSDN:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh994433(v=vs.85).aspx

Navíc můžete vytvářet dump nebo minidump, a ten pak analyzovat. Pokud se systém složí, po příštím bootu (ehm, pokud proběhne) vás vyzve k zaslání hlášení společnosti Microsoft. Pokud pro daný problém existuje řešení, je vám zobrazeno. Pokud ne, uchová se informace pro další analýzu. Když MS například zjistí, že uživatelům působí problém nějaký konkrétní driver, řeší to pak s výrobcem. Ve Win7 a výše se drží seznam hlášených problémů, a pokud se objeví řešení později, jste upozorněn.

Za mě je to řešené celkem pěkně.

Vy asi čtete dost selektivně :). Psal jsem, že v oblasti HW neexistuje moc standardů, a většinou jde o doporučení. Pokud HW umí něco navíc proti specifikaci, není to bug. Pokud některé operace nepodporuje, nemusí to být bug. Pokud mají nějaké operace na různých HW různou rychlost, není to bug.

BTW jeden příklad: ve většině PC najdete interface I2C, na který je připojená spousta věcí, včetně chlazení. Na jedné straně máte nějaký I2C controller, který může být řešený prakticky jakkoliv. Neexistuje žádný standard, jen hromada chipů, které navíc můžete zapojit různými způsoby. Na to je pak pověšená nějaká zařízení - na každém systému jiná. Nemáte šanci vědět, jaká zařízení tam jsou, ani jak s nimi máte komunikovat. A i kdybyste věděl, že jedno z těch zařízení je konkrétní čip ovládající ventilátor pomocí 8-bitové hodnoty, pořád ještě nevíte, že výrobce používá řekněme jen 5 bitů, a hodnoty pod 4 způsobí zastavení ventilátoru. A na příští základní desce toho samého výrobce může být všechno jinak.
A jak se potom píše funkční generický driver? Vezmete si HW na vašem počítači, a budete předpokládat, že všude jinde je to udělané stejně. Když místo změny otáček ventilátoru sáhnete někam jinam, dost možná něco nabouráte, a pak budete nadávat, že se výrobce "nedrží standardu". Jenže žádný standard neexistuje.

Specifikace ACPI má 950 stránek, vyžaduje implementaci AML byte code na straně OS, a dává výrobci spoustu volnosti. Při stovkách výrobců HW a tisících modelů mainboardů těžko můžete čekat, že si všechno sedne jak má. Jako perličku bych uvedl, že u některých polí nebylo až do ACPI verze 4.0a jasné, jestli mají být stringy null terminated.

1) I2C je standardní rozhraní, který si patentoval a standardizoval Philips. To, co po těchto dvou drátech běhá, je standard.
2) V PC se nepoužívá I2C, ale SMB - System Management Bus. Jsou tam nějaký drobný změny proti I2C, aby se vyhnuli výpalnýmu.
3) SMB Master je obvykle v chipsetu. Toho je kolik? Když budou v průměru dva čipsety pro každou rodinu CPU a pět rodin CPU na trhu, tak neříkejte, že se při troše snahy nepodaří odladit max. 10 variant železa, kde má navíc výrobce svoje odladěný reusable moduly a plácá je na čipy podle potřeby.
4) Periferky na SMB jsou +/- standard - minimálně 24C04 a jejich adresování na modulech RAMky (to je to nejdůležitější). Pak stačí mrknout na desku na ostatní brouky. Málo kdo si bude dělat vlastní čipy nebo programovat jednočip, když má věci jako MAX6652 nebo MAX1619. Stačí dohledat datasheety. Není to standard, ale je to dobře popsaný. Komunikace (adresy, hodnoty) se dá dobře nasniffovat na patici pro DIMM moduly.

A kupodivu, ten brouk se i představí, např. posledně zmíněný MAX1669 má registr 0xFE = 0x4D (Maxim), 0xFF = 0x05. Když ho najdu na nějaké reálné adrese, vím, co do něho poslat. Jenom si vyzkoušet, ketrou teplotu že měří a kterým větrákem že točí.

Problém nastane jenom v případě, že se jim to zdá drahý a narvou tam nějaký jednočip (ATXmega, MSP430,..). Pak nastoupí hrubá síla pervers inženýringu...

Jinými slovy existují jisté standardy, ale ty toho popisují málo, a pokud nemáte informace ke konkrétní základní desce, tak se jen dohadujete. To ještě odhlédnu od toho, že si s těmi větráky přes I2C/SMBus může povídat BIOS/ACPI, případně nějaký driver, takže v tom budete mít slušný chaos.

Ok, nějaký nestandarní chování... Řekněme, že máme PC takových pět let starý, s nějakým "systémem na doma" ve verzi 98. nějaký expert si hraje a zapíše na IO port (libovolnou adresu). Určitě nic nerozbije, když systém interně vyvolá výjimku, která povolí aplikaci od teď na furt zapisovat do železa... Jaj, co jsme se ve škole tímhle způsobem nahráli s COM, LPT a game portem přímo z formuláře v Delphi. A občas, vinou systému, něco sejmuli. Práce operačního systému je totiž mj. i to, aby odstínila železo za ono "standardní rozhraní" a aplikaci k tomu vůbec nepustila. Tohle chování W95/98 je jedna z největších prasáren, co jsem v životě viděl. A zneužívali to i výrobci železa, třeba garážový firmičky bez nějaké kontroly kvality SW s portfóliem dvou PCI karet - jedné s 32 neoddělenými TTL vstupy, druhé s 32 neoddělenými TTL výstupy a malou aplikací pod Win pro řízení. Prostě proto, že to šlo.

Btw. za ty mechaniky viním autory standardu - měli jasně definovat provozní režimy zařízení RUN, DIAG a UPDATE V UPDATE ať si výrobce dělá co chce a s čím chce, v DIAGu ponechat prostor pro proprietální, nedestruktivní testy, ale zbytek MUSÍ být přesně podle standardu a přes to nejede vlak. Nebo snad neexistuje rozhraní i na úrovni systému a periferie? Resp. nemůže být standardní? A generický ovladač OS nemůže tohle rozhraní prostě jenom zapouzdřit 1:1 bez dodatečné práce a obtěžování uživatelů instalací?

Windows 9x byly takové jaké byly ze dvou důvodů: kvůli nižší HW náročnosti, a kvůli kompatibilitě s programy psanými pro DOS a starší verze Windows.

Pokud jsem si všiml, tak operace typu testů a flashování firmware nemají ve většině specifikací popis. On to totiž každý výrobce řeší jinak, takže není moc co standardizovat.

Generický ovladač může jen zapouzdřit "standardní" rozhraní. Problém je v tom, že HW je obrovská spousta, a různé modely mají svá specifika. Těžko můžete čekat, že výrobci budou vyrábět jen to, pro co existuje specifikace (mimochodem často mizerně napsaná), a budou se jí kompletně držet.

Kecy v kleci. Na ochranu se využívají protect módy procesoru, je to řešeno hardwarově na straně procesoru (ochrana přímo v x86 neumožňuje instrukce In a Out, pokud není v privilegovaným režimu). Ta ochrana byla aktivní i na W95/98, takže nárok na HW to nepředstavuje. Naopak, tady se ochrana aktivně obcházela.

Co se týká backward kompatibility, tak přece aplikace pro starší verze a pro DOS běhlay na podstatně slabším HW (268@16MHz vs 486SX6@66MHz) a při troše snahy by nebyl problém nastavit spouštění v sandboxu a přidělení periferky v nějakým .ini souboru nebo v registrech. Na výkonu staré aplikačky by se to ani nepoznalo.

Takže bezpečnostní kráter jak kráva, uměle vybagrovaný kvůli šlompáctví a zdechlosti zodpovědných jedinců...

HW náročnost se týkala spíš podpory Unicode. Na 4MB RAM si nemůžete moc vyskakovat.

Se zpětnou kompatibilitou se mýlíte. Ono totiž nešlo zdaleka jen o aplikace. Win9x uměly používat například drivery psané pro DOS. Navíc pokud byste chtěl povolovat I/O pro každou aplikaci, byl by výsledek velmi podobný stavu, kdy povolíte všechno - jenom byste musel vytvořit definice minimálně pro desítky tisíc aplikací, což v praxi není realizovatelné.

Pokud vím, tek pod DOSem se nelezlo přímo na železo, ale většina z toho valila přes SW interrupt (klávesnice, myš,...) To ten "systém" musel emulovat tak jako tak. Přímo na železo toho lezlo minimum (proč by takový T602 lezl na COM2?), přestřelme to, dejme 1% aplikací. Nebylo by potřeba nastavovat to pro každou, prostě by default, aplikačka nesmí na železo a emuluje se BIOS + VGA. Pokud někam potřebuje, spustí se driver simulující železo a zeptá se, jestli povolit aplikaci X přístup k prostředku Y. Odpověď se uloží a je to. Při prvním spuštění je to 20s pro uživatele a jedno kliknutí. Rozhodně by to bylo víc user friendly, než když strčím flash disk do komplu s Win 7, vyskočí bublina s informací o novým HW, 10 minut hledá drivery, pak nahlásí chybu a po dvou dalších pokusech se konečně zeptá, jestli má udělat scan na dalších pět minut.

Chce to jenom mystet out of the XBOX :D

T602 lezl na paralelní i sériové porty, protože se na ně dá připojit tiskárna. Představa "firewallu pro přístup na železo" je zajímavá, ale velmi špatná. Těžko to uděláte třeba u driverů psaných pro DOS, u full screen aplikací, a hlavně to uživatel nebude schopný používat. Ta GUI firewallů, s věčnými dotazy typu "aplikace abcde.exe chce přistoupit na adresu 11.22.33.44 port 5432, povolit/zakázat/po­volit vždy?", jsou myslím dostatečně odstrašující ukázkou. Dalším problémem je to, že byste se u většiny aplikací musel ptát opakovaně, protože využívají typicky víc portů. Ve spoustě případů ovšem ty dodatečné porty použijí jen ve chvíli, kdy se něco stane (přijde událost A, pošlou něco na port XYZ). Jednak je to na zabití, a pak vám to může zásadně poškodit časování komunikace s periferií.

U driverů byl problém hlavně v tom, že pro řadu HW prostě nebyly. Třeba pro I/O karty, ale i pro některé mechaniky CD-ROM a síťové karty. Ještě v roce 1998 se našli výrobci, kteří s HW nedodávali drivery pro Windows :/

Uživatel samozřejmě zaskrtne "Remember choice" a odklepne Yes. Hlášce totiž nerozumí. Navíc se ho systém ptá mnohokrát za den na tu samou věc, jen se liší pár údajů. Je to ukázka špatné usability.

To je jeden důvod, proč to nepomáhá. Další důvody:
- Pokud má malware oprávnění administrátora, může vypnout firewall, nebo vložit výjimku.
- Pokud má uživatel oprávnění vypnout firewall nebo vložit výjimku, může to udělat i malware běžící v kontextu uživatele.
- Není problém, aby malware komunikoval se sítí pomocí knihovny natažené v hostitelské aplikaci, která má přístup na inet. Například plugin browseru. Nakonec se ale dá browser skriptovat z externí aplikace, tak proč ztrácet čas psaním pluginu :)

Uživatel nezná jména executables, nezná doménová jména, nezná čísla portů, a netuší co kam smí nebo nesmí komunikovat (nehledě na to, že není problém vytvořit malware se jménem executable iexplore.exe nebo firefox.exe). Uživatelé jsou lidé, kteří se nechají nachytat na phishingové zprávy, protože po odkliknutí linku vidí v URL název své banky, a nepřijde jim divné, že je to nějaká fourth-level doména na čínském webu. Ne každý vystudoval informatiku a/nebo ovládá základy TCP/IP.

Znovu opakuji, že ti uživatelé dostávají spoustu otravných hlášek každý den, a vůbec jim nerozumí. Prostě to nefunguje.

Na běžném počítači jsou tisíce executables (u mě je jich 6800), aktualizace a/nebo service packy se instalují nejméně každý měsíc. Navíc jsem už psal, že uživatel nezná jména executables; ani já nedovedu každý z těch 6800 kousků vždycky přiřadit k aplikaci. K tomu uživatel nerozumí IP adresám a portům. Proč myslíte, že ty firewally pro odchozí provoz skoro nikdo nepoužívá?

Jediným správným řešením je zabránit průniku malwaru použitím antiviru, instalací EMETu, a rozumným chováním uživatele. Pokud se uživatel neumí chovat rozumně, je potřeba mu zatrhnout všechno co nepotřebuje, případně použít Windows RT.

Jenomže pod DOSem běžela jedna aplikace. Pokud ji zatáhnu někam, kde existuje multitasking a periferku si nárokuje "kde co", tak je jenom otázka času, kdy jedna aplikace zboří nastavení druhé, nebo se něco pošle nekorektně... Právě z tohoto důvodu MUSÍ být taková aplikace na pískovišti a nevrtat se přímo v železe. Co když se pokusí si přisvojit systémový časovač, protože vnitřně používá multitasking?

Praktcké realizace:
- Aplikace se dostane k instrukci IN nebo OUT
- Procesor hodí přeručení pro neprivilegovanou instrukci
- Přerušovací rutina obslouží I/O operaci, nebo v případě problému (zákaz, periferka obsazena) raděj zabije aplikaci, než nezabrání destrukci systému.
- Widle snad mají drivery a předpokládám, že když eperti z MS dokázali odělat dialog vlastností, kde je vidět přiřazení adres periferkám, tak by mohli umět napsat i něco, co místo "... na port 0xXXXX" napíše "... na periferii Y" a povolí rovnou celý rozsah adres periferky - je jasný, že když zapíšu baudrate do UARTu, asi budu potřebovat ještě datový registr a někdy třeba i handshake registr... Ale vždycky aplikace pracuje s celým portem.

Systémový časovač je virtualizovaný, stejně jako některá další zařízení. Těžko ale můžete virtualizovat zařízení, ke kterému nemáte driver. V době uvedení Windows 95 navíc nebyl zdaleka všechen HW plug&play, takže OS neměl úplnou představu, jaká zařízení v systému jsou, a jaké prostředky používají . A jak jsem už psal, pro spoustu HW byly drivery jen pro DOS.

Aby to bylo ještě zajímavější, Windows 3.x používaly kooperativní multitasking a běžely ve sdíleném adresním prostoru. To aplikaci dávalo možnost implementovat IPC přímým zápisem do paměti jiného procesu, vytvořit handle a předat ho jinému procesu atd. Ve Windows 95 to bylo vyřešeno tak, že se pro 16-bitové aplikace používal kooperativní multitasking, a context switch se provedl jen pokud 16-bitová aplikace volala systém (jako ve Win3.x). U aplikací pro DOS se používala nastavitelná heuristická detekce idle stavu, vizte screenshot.
http://doomworld.com/drsleep/dstep3.gif

Wndows 9x byly plné drsných kompromisů, ale zajistit tak širokou zpětnou kompatibilitu jiným způsobem prostě nešlo. MS počítal, že uživatele rychle převede na Windows řady NT. Bohužel zákazníkům Win9x vyhovovaly, řada výrobců ještě léta dodávala drivery jen pro DOS, a mainstreamoví uživatelé přešli na řadu NT až s Windows XP. Firmy samozřejmě často přešly už na Windows NT 4.0, tak jako tedy u nás. Podmínkou byla kompatibilita HW a SW s NT, plus větší množství paměti (která tehdy výrazně zlevnila, ale přesto byla dost drahá).

BTW pro aplikace, které pod Win9x prostě nešly rozchodit, byla k dispozici option "Restart the computer in MS-DOS mode". Touto volbou jste mohl aplikaci pro DOS pustit exkluzivně, na lehce upraveném "kernelu" DOSu, a po jejím ukončení restovat zpátky do Windows. Samozřejmě to nebylo ideální, ale pro některé aplikace nebyla jiná cesta.

Virtualizovat jistě ne, ale dá se pustit na železo výhradně za podmínek, že
- je vymezený prostor, kam ta aplikace smí
- je zajištěno, že tam bude přistupovat sama (tj. nespustí se dvě instance programu,...)

Takže "ovladač" volaný přerušením od neprivilegované instrukce koukne, jestli je adresa v povoleným rozsahu a jestli má mutex. Když jo, provede instrukci. Když ne, zabije natvrdo aplikaci. Sice je tam jedna mezivrstva v jádře s nějakou malou režií, ale zabespečení systému před pádem a konzistence dat v aplikaci vám za to nestojí?

Ale to přiznání, že nejsou ovladače do widlí pro všechno, je skoro tak krásný, jako to přiznání, že W95, W98 a W ME byly hnusnej bastl a atrapa systému...

Ad je vymezený prostor, kam ta aplikace smí - jak tohle chcete zařídit, když pro zařízení nemáte drivery a v mnoha případech ani nevíte o jeho existenci?
Ad je zajištěno, že tam bude přistupovat sama - to samé

Ad nejsou ovladače do widlí pro všechno - jak jsem psal, ještě v roce 1998 se našli výrobci, kteří dodávali drivery jen pro DOS. Nic krásného na tom nevidím.
Ad W95, W98 a W ME byly hnusnej bastl a atrapa systému - Windows 9x byly SW, který měl uživatele Win3.x přivést k Windows řady NT, a zpětná kompatibilita vynutila řadu kompromisů. MS ten přechod ovšem zvládl výrazně lépe, než třeba Apple.

Windows 95 poskytovaly prakticky stejné Win32 API jako Windows NT, a jednou z podmínek certifikace SW pro Windows 95 byl jeho běh i na řadě NT.

NT 4 neměly podporu USB, ale šlo doinstalovat podporu od výrobců HW. BTW první USB klíčenky přišly na trh až v roce 2000, kdy jste už mohl použít Windows 2000.
DirectX bylo podporované ve verzi 3.0a, a neoficiálně jste tam mohl nacpat i DX 5. Navíc v roce 1996 bylo minimum her i pro Windows 95, a většina z nich používala OpenGL (které v NT4 mělo podporu).
Device Manager v NT4 opravdu nebyl. Regedit byl převzatý z Windows 95, a neuměl permissions; regedt32 uměl permissions, ale měl GUI Windows NT 3.51.
Ad NT 4.0 MS honem nejak poslepoval dohromady - NT 4.0 vycházejí z NT 3.51, s GUI z Windows 95 a pár dalšími změnami (DirectX, přesun GDI do kernelu apod).

Výhodou NT 4 byla samozřejmě stabilita a bezpečnost (mimochodem tehdy se mělo za to, že je výhodou i podpora více platforem, což se ukázalo jako naprostý nesmysl). Pokud firma používala aplikace kompatibilní s NT (tedy například kancelářské aplikace), a měla na slušný HW, byla to velmi dobrá volba.

Zapomněl jsem na úžasné Unixové systémy. Mohl jste si pořídit server na Unixu, 10x dražší než na Windows, k tomu admina, DB admina, network admina... A samozřejmě existovaly (a asi ještě existují) i Unixové workstations. Dneska na nich nejspíš spustíte i OpenOffice - tehdy bohužel ne. Zato měly jiné vychytávky: u Sunu se monitory připojovaly přes zvláštní konektor, a jejich optické myši fungovaly jen na podložce od Sunu (myši byly laserové a používaly mousepad s natištěným rastrem).

Původně jsem četl jednoho admina na pět set PC, a pak jsem zjistil, že jste podstatně pesimističtější :). Většina českých firem jela dlouho na Win9x, a poměr adminů (a "aminů") a uživatelů měly minimálně o řád vyšší.

Naprosto jednoduše.

Existují privilegia pro procesy, jdou definovaný už na HW. Pokud nemá běžící kód povoleno použití instrukcí IN a OUT, jádro procesoru vyhodí výjimku a udělá se to v jejím ošetření. Ve statusu chyby procesoru se dá najít adresa instrukce, co to bylo za instrukci a kam lezla. Takže detekovat, že program někam sahá, není absolutně problém a běh programu to nezbrzdí (mimo "delší" instrukce IN a OUT).

V obsluze přerušení se dá definovat jeho obsluha podobně, jako u TRAPu pro volání systému. A tam už stačí mít nějakou hloupou tabulku - rozsah, momentálně přiřazená aplikace (reprezentace pomocí process ID).
A obsluha zajistí pomocí nějakýho procesu na pozadí následující akce:
- při prvním přístupu ověí ze známých ovladačů, jestli je pro ni ovladač (podle adres)
- u periferky bez ovladače při prvním přístupu nabídne povolení rozsahu
- u periferky s ovladačem se podívá, jestli ji někdo používá a když ne, tak si ji zabere pomocí mutexu
- pokud je už rozsah používaný, sestřelí volající aplikaci s odpovídajícím hlášením
- pokud je rozsah v tabulce volný, ověří, že tam aplikace smí (záznam v registrech, dotaz). Buďto ji zabije, nebo provede na úrovn ovladače požadovanou instrukci.
- po ukončení aplikace uvolní mutex a smaže z tabulky všechny její process id (stačí hook do zpráv aplikaci, aby poznal zavření)

To je fakt tak složitý, že je to u M$ nerealizovatelný?

OMG. Ještě jednou: v době Windows 95 spousta HW nebyla PnP, a na spoustu věcí nebyly drivery, takže Windows o existenci daného HW nevěděly - neměly seznam jeho I/O portů a bufferů. Detekovat kam program sahá jen není problém. Problém je, co s tou informací udělat, když nemáte driver, a nevíte co na tom portu visí (a nebo nevisí). Navíc aplikace nemusí běžet v jediném procesu, a s HW si může povídat víc procesů najednou. Navíc otázkám na povolení přístupu k HW nebude uživatel rozumět, tak jako nerozumí dotazům firewallu. Navíc u full screen aplikace budete těžko zobrazovat dotaz. Navíc to neřeší problém driverů psaných pro DOS. Je to past vedle pasti, (c) mechanik Luboš, a proto MS touhle cestou nešel. Nabídnul virtualizaci běžného HW, s tím že zbytek se nedal efektivně řešit, a aplikacím se proto přístup neblokoval.

Samozřejmě v NT to bylo (a je) jinak: aplikace psaná pro DOS nebo staré Windows buď použila virtualizovaný HW, nebo měla smůlu. To je samozřejmě jediný konzistentní přístup, ale nebudou vám fungovat drivery psané pro DOS, ani aplikace komunikující napřímo s HW.

Ježíšmarjá, jděte už všichni spát.
Vaše proaktivita bude šéfem oceněna, tak už neotravujte.

No jo no... ale pokud se ne to podíváme očima jinýma, než nadšeného zastánce windows, tak by situace mohla vypadat třeba takto:

NTB samsung - výrobce nedodal driver, nedodal dokumentaci, zdroják, nedodal vlastně nic jen jakousi neoficiální poznámku o tom, jak to funguje a která se netýkala nového modelu, což ale také nikde nezmínil... ale jinak je v tom zcela nevinně;-)

Mechaniky LG - výrobce implementoval nedokumentovanou funkčnost, nedodal driver, dokumentaci, zdroják, ani tu poznámku.... a ne - korektní chování na nepodporovaný příkaz dle mého názoru není bricknout zařízení (analogie - pád prohlížeče při neznámém HTML tagu).

Ono je reálně tolik pravd, kolik je pohledů na věc. Nelze všem vnucovat ten jediný "politicky korektní".

Ad NTB Samsung - výrobce dodal driver pro Windows. Nevíme jestli s ním vůbec někdo mluvil o driveru pro Linux, nebo o specifikaci. Driver asi nedodá, protože autoři Linuxu tvrdí, že kernelový modul musí být pod GPL, neexistuje kernelové ABI, a Linux je roztříštěný na stovky dister s novými verzemi co pár měsíců. Pro 99% uživatelů stačí napsat testovat drivery pro poslední verzi Windows, a ro zbývající jedno procento má stovky dister plus všechny ty z hlediska výrobce úchylné podmínky - co pak čekáte?

Ad mechaniky LG - výrobce *musí* implementovat funkce, které ATAPI nepopisuje, protože update firmwaru v té specifikaci prostě není. Driver není potřeba, protože je to standardní ATAPI CD-ROM. Utilita pro flash firmwaru byla nejspíš pro (Free)DOS. Ohledně dokumentace opět netušíme, jestli s nimi vůbec někdo mluvil.

Minimalistické řešení: vytvořit standardní testy HW (podobně jako je má Microsoft), například formou live distra, která po bootu prostě otestuje co může. Vytvořit centrálně spravovanou databázi modelů HW, výsledků testů a řešení. Řešením může být úprava kernelu/driveru, nebo nějaké nastavení, které by pak mělo být k dispozici na každém instalačním médiu, s možností online updatu, a automatickou aplikací toho řešení. A samozřejmě pokud chcete drivery od výrobců, tak je třeba vytvořit ABI, stabilizovat vývoj tak aby nové verze dister nevycházely co pár měsíců, vyjmout drivery z GPL a minimalizovat počet (podporovaných) dister. Vzhledem k počtu uživatelů Linuxu by se výrobcům možná také slušelo za drivery a podporu zaplatit.

Jak vidíte, tak řešení vázne na straně Linuxu. Nejsou zdroje na psaní driverů pro existující HW a jejich testování (kdyby uživatelé platili za distro Linuxu jen desetinu ceny Windows, hned by peníze byly). K tomu politika FSF a autorů jádra brání kooperaci s výrobci. Na co si pak stěžujete? Vždyť si ty problémy způsobují autoři Linuxu sami.

Pro komunikaci platí několik pravidel:
1. Pokud zpráva nesedí se specifikací, nedělám nic a vrátím chybu "UNSPECIFIED OPERATION".
2. Pokud potřebuju něco, co standard nepodporuje a musím si doplnit zprávu, MUSÍ protistrana explicitně potvrdit, že tuhle funkcionalitu požaduje. Jinak viz 1.

Takže pto flashování to měli udělat tak, že po příkazu pro zápis je vrácen chyba, pokud do nějaké doby přijde specifikovaná zpráva s klíčem, přepne se do FLASH režimu.

Když to dělalo LG tak, že operaci potvrdili a neověřovali, jestli jde o cílenou akci, tak sice v Linuxu byla prasárna, ale destruktivní byl přístup LG. Není to zařízení, ketrý by bylo ve vzduchoprázdnu a profesní paranoia a pan Murphy velí k obezřetnosti.

2. Protistranou má být standardní ATAPI CD-ROM driver, a ten nemá důvod posílat funkce, které nejsou ve specifikaci. Samozřejmě lze HW lépe zabezpečit proti vadnému SW. Ale pointa je v tom, že SW byl v popsaném případě vadný.

Neříkám, že ten driver byl v pořádku, ale pokud je ve funkci, která má na starost komunikaci s jiným systémem, na posledním řádku return ERR_OK, tak je to na zastřelení. Funkce nesmí jako default vracet, že proběhla bez problémů a kontrolér nesmí provést akci, u které nemá jistotu, že ji provést má.

Pokud driver volá funkci X daného zařízení, má zařízení jasně provést funkci X.

Ad pokud je ve funkci, která má na starost komunikaci s jiným systémem, na posledním řádku return ERR_OK, tak je to na zastřelení - a tohle byl takový případ?

Vadny je HW... ktery se necha SW znicit. A to plati odjakziva a vzdy to platit bude. Za tvy pindy by ti lecjakej ucitel dal rovnou preshubu, protoze prave kvuli takovejm dmntum veci nefungujou.

Jakýkoliv HW, který umožňuje update firmwaru ze SW, lze pomocí SW odstavit.

Nelze, ale to tupec jako ty nemuze pochopit. Jakykoli normalni HW totiz ma cast (zcela neprepsatelnou) ktera mu umoznuje byt preflashovan. Lepsi kousky pak maji i rezervni firmware. Pokud nema ani jedno, je to chyba vyrobce.

Milý J, zkuste si všimnout několika věcí:
- Nazýváte mě tupcem. Kdyby vám snad nedocházelo, že takové věci do diskuse nepatří, tak si přečtěte pravidla pro diskutující pod polem, do kterého píšete příspěvek.
- Pokud vám někdo vyká, je dobrým zvykem mu také vykat.
- V diskusích opakovaně předvádíte těžkou neznalost problematiky, ke které se snažíte vyjadřovat.

K tématu: většina HW nemá nepřepisovatelnou část flash memory. Zvyšuje to náklady a snižuje flexibilitu (pokud se v nepřepisovatelné části vyskytne chyba, nelze ji opravit). Navíc to uživateli nepomůže. Když mu například umře základní deska díky špatně flashnutému BIOSu, tak je mu úplně jedno, jakým způsobem ji pak support/servis rozchodí. Sám to nezvládne, a jeho HW je prostě odstavený.
Záložní firmware je naprosto výjimečná záležitost. Může mít smysl, ale opět to přináší náklady navíc, a k tomu uživatel musí vědět, jak záložní firmware aktivovat.
Firmám se prostě nechce zvyšovat náklady - a tedy ceny - kvůli hypotetickým situacím, které nakonec postihnou řekněme jednoho zákazníka ze sta tisíc, a to řešení se zvýšenými náklady by mu stejně moc nepomohlo (vizte výše).

Zrovna u mainboardu notebooku má ten flash minimum šancí neprojít. V instrukcích bývá psáno, že máte mít plnou baterii, takže vás netrápí výpadek proudu. Nesprávný firmware nezapíšete, protože to utilita ověřuje. Po flashi se provádí ověřovací čtení.

Samozřejmě pokud vám omylem ten firmware přepíše nějaký linuxový driver :), tak máte smůlu. A když vzácně mainboard má nějakou recovery option, tak to stejně nebývá nic pro uživatele:
http://support.lenovo.com/en_US/research/hints-or-tips/detail.page?&LegacyDocID=MIGR-45385

Pokud na displayi svítí velký nápis "DO NOT power off or reset system", a on systém vypne nebo resetuje, tak je to obdobou toho, když si uřízne prst kuchyňským nožem. Při některých věcech si člověk holt musí dávat pozor.

Linkoval jsem recovery BIOSu u nějakého HW od Lenova. Osmnáct kroků, včetně rozebrání počítače a přepnutí jumperu - to fakt není pro každého. V některých případech je to jednodušší, ale pořád ne dost jednoduché pro uživatele (sehnat klíčenku, na jiném stroji ji naformátovat na FAT32, stáhnout image BIOSu, rozbalit ho na klíčenku, provést nějaký magický hmat při startu počítače).