Vlákno názorů k článku
Červnová aktualizace Windows 11 rozbíjí dialog při vysypávání koše
od Lukas1500 - Obdivuji programátory, kteří si troufnou v takto rozsáhlém...
-
Ako softvérový Inžinier pre nadnárodnú korporáciu môžem zo skúseností povedať že problém neudržateľnosti softvéru je najčastejšie spôsobené nie programátormi, ale vyšším manažmentom, prípadne Product Ownermi. Taktiež môžem povedať že ak máš schopných ľudí vo vyššom manažmente a dobre nastavený systém, tak vývoj a udržateľnosť aj tak gigantického softwaru akou je Windows je veľmi jednoduchá vec. Programátori a architekti často majú nižší vplyv na kvalite finálneho produktu (alebo produktu nazvanej "ako služba").
-
Nuze, vy tomu celkom fandite, ze pred desiatimi rokmi.
Mam bohuzial tu cest momentalne pracovat na kernel-side komponente a doba, kedy sa z NT kernelu stala kopa odpadkov by sa dal zhruba oddatovat do ery Windows 2000. To uz bolo dielo skazy do znacnej miery dokonane.
Vovnutri je to disjunktny bordel s typovym systemom plnym pasci, je v tom hromada presakujucich nekompletnych abstrakcii; vela veci vyzera byt pisanych ad-hoc (napr. na tej istej urovni existuju dva vzajomne nekompatibilne sposoby ako zadat ACL na ktore sice konverzna rutina existuje, ale len v userspace) a cele to zaklincuvava odporna dokumentacia.
Je to tak zle, ze je asi na mieste aj spochybnenie statusu Davea Cutlera ako legendarneho programatora. Za predpokladu ze sa na tom koncom 90. rokov este podielal.
-
To ze jednu vec muzes delat 10ti zcela nekompatabilnima zpusobama je ve widlich standard odjakziva ... vdycky prijde nejakej frikulin a zacne vymejslet nejakej novej zpusob, kterej nikdy nikdo nedodela, a tak nefunguje, stejne jako vsechny ty predtim. Zato ty starsi zpusoby jeste typicky rozbije tak, aby nefungovaly vubec.
-
Velmi rád bych si s Vámi jádře NT někdy popovídal. Sám udržuji jen upatlaný driver pro ISA, USB, PCIe uLAN komunikaci od dob Windows NT 3.1 a postupně jsme ho zvládli udržet ve stavu funkčním s přidávanými PnP a Power službami a požadavky. Nejsem fanda Windows, userspace považuji za úplný horor, socket() v jiném index/handle namespace než open(), důsledek popírání IP protokolu a před tím chráněného režimu atd... Ale na druhou stranu na vrstvě systémových handles pod tím vším po přechodu na NT a systému IRP vidím i kus značné invence. Kde za mě je hlavní ošklivost to, že drivery musí vědět do kterého FDO, PDO, IRP stacku půjdou, protože systémy pro předání dat jsou tři a pokud vím, tak jsou silně nekompatibilní, nevím jestli lze z režimu předání mapou přejít na režim kopírování do kernel space a opačně, když by se použily různé varianty driverů v jednom stacku. Myslím, že minimálně dříve to nešlo ani za cenu ztráty výkonu.
Z dnešního pohledu proti IOUring, folios a dalším, co je nabízené jádře Linux, je přístup NT již dětská hračka, stejně tak IRQL Dispatch, který pokud vím, je stále nepreemptivní. Ani nevím jestli již dořešili na Windows zásadní protisystémovou koncepci, kdy chybí priority inheritance.
Ale obecně se mi zdálo že tam kus umu byl a zajímá mě, jestli/kde se to přímo v těch spodních zkazilo.
-
Mně zase naopak připadá, že mít ten samý typ handle na file a socket je poněkud úlet. Ale na úrovni vyššího programovacího jazyka, kam bych odvážně zahrnul i C++, přece není problém vytvořit abstrakci. Například v .NETu StreamReader operuje nad FileStream, NetworkStream, HttpRequest.InputStream atd.
Ty „systémy předání dat“ jsou spíš tři způsoby přístupu k bufferům: Buffered I/O, Direct I/O a Neither buffered nor direct. Všechny drivery ve stacku mají pro daný request používat stejný způsob přístupu k bufferům, s výjimkou případného nejvyššího driveru, který může použít „neither“ bez ohledu na nižší drivery. Předpokládal bych, že drivery ve stacku nekombinujete zcela náhodně, takže by to neměl být problém.
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/methods-for-accessing-data-buffersIO_Uring? Windows mají I/O Completion Ports (IOCP) / Overlapped I/O, Registered I/O (RIO) a IoRing.
Folios? To je jistě zajímavá technika, s tím že Windows používají více technik, které plní podobný účel. Rozumím, že například end-to-end podpora I/O requestů větších než 4kB je na Linuxu fascinující horkou novinkou. Ve světě Windows je to ovšem věc stará 20 let.
Na IRQL DISPATCH_LEVEL je zcela záměrně na daném CPU možná preempce pouze vyšší úrovní HW interruptu, případně system-critical interrupty. Kód běžící na DISPATCH_LEVEL by měl být velmi krátký, do 100 µs. Mimochodem, chce dost kuráže kritizovat IQRL a preempci ve Windows ve chvíli, kdy na Linuxu máte preempt_disable(), a k tomu big kernel lock, který sice byl "už" po 20 letech odstraněn, ale místo něj máte dodnes(?) obdobné subsystem-level locky typu rtnl_lock nebo console_lock.
-
100 µs je pro real-time již často nepřípustná doba. Linux kernel kompilovaný ve fully-preemtive režimu na x86 HW, který nemá problémy s BIOSEM a MSI interrupty zvládá maximální latence pro user-space task s nejvyšší RT prioritou latence pod 20 µs s tím, že ani jeden vzorek za týdny provozu není vyšší. Takže opravdu nějaký blokující dispatch by to zlikvidoval. Dále je možné řešit izolaci některého CPU a dostat se odsunutím RCU a dalších servisních vláken ještě na kratší latence. Vše toto chodilo na patchovaném jádře již před 20 lety, ale požadavky vstup do mainline a ošetření všech mezních případů si vyžádali 20 let vývoje. Souhlasím, že networking je na tom, co se latencí týče, stále o hodně hůře.
Co se týče limitace, že na socket nelze normálně udělat na Windows fdopen a pak fread/fwrite/fprintf atd, tak je to celkem otrava, přitom na úrovni interface jádra je to celkem správně. WaitOnMultipleObjects omezený na 64 událostí nění moc šikovný, completions něco dají, ale opět tím, že sockety jsou nalepené z BSD (původně Trumpet Winsock, když MS roky existenci Internetu popíral) tak to dohromady s I/O devices, sériovým portem, atd. moc dobře nevychází. Řízení worker poolu je as rozumné. Ekvivalent I/O Uring, pokud vím, MS do Windows přidal až podle vzoru Linux kernelu. Co se týče správy paměti, tak zdrojáky jsem vidět nemohl, ale popisy protopages extries pro zajištění sdílení knihoven a regionů mezi procesy a další minimálně dříve, kdy jsem k tomu ještě dohledal dokumentaci, byly hodně nešťastné.
Jinak Linux kernel různé I/O vec a dlouhé kontinuální úseky, huge pages a mnoho dalšího umí také desetiletí, folios jsou přepracování na snížení overheadu na minimum. Jak moc velký vliv to má neumím posoudit, ale autoři jsou předvědšční a deklarují, že značný.
Takže obecně si myslím, že jádro Linuxu není na rozdíl od sice precizně definovaného základ NT, vázané binární kompatibilitou driverů a v současné době je si myslím, že je o dost modernější než NT.
-
Da sa to, ale jednoducho povedane, kazdy by sa mal hrat na svojom piesocku. Cize, ty riesis stale len jednu malu konkretnu cast a s okolitym svetom komunikujes cez API, kde su jasne dane vstupy a vystupy. Sice, niekedy je to tazsie, ked potrebujes nieco specialne a prave vtedy prichadzaju tie chyby. Ty si nieco "priohnes", lebo to tak potrebujes a uz sa spusti lavina zavislosti.
Pracujem v korporate, nie je to sice vyvoj OS, ale aj tak ten system je dost velky moloch. A aj ked pracujem na malickom module, ktory je zavisly na x-dalsich, tak neustale riesim problemy, kedy niekto urobi drobnu upravu u seba a mne sa to zosype. Ale aspon nemam v praci stereotyp :)