M:N threading je opravdu teoreticky lepší, ale v praxi ho nikdo nedokázal implementovat tak, aby nebyl výrazně složitější než 1:1 threading. Na systémech, jako je třeba starý Solaris, které mají kernelové context-switche ukrutně pomalé, samozřejmě M:N threading pomůže; pokud jsou ale kernelové switche rychlé, nemá jak pomoci, pouze může uškodit.
Ad accept filtry: hezký trik, ale pomůže doopravdy? Například u HTTP GETu je pravděpodobnost toho, že přijde "GE" jedním packetem a "T" až dalším, efektivně nulová. Navíc pokud je server pod zátěží, většinou má context-switch na proces, který se stará právě o toto spojení, trochu opozdí a mezitím request stihne dorazit celý.
Souhlasím, že linuxový IDE driver je složitý a nepřehledný a místy ošklivý, jenže alespoň polovina té ošklivosti tkví v hardwaru, se kterým se musí bavit. Tolikeré obcházení hw bugů se hned tak někde nevidí. Navíc IDE driver není jeden driver, ale spousta driverů na různé IDE controllery. Když se podíváte na driver jednoduchého zařízení, opravdu bude jednoduchý a pěkný. Popisujete-li ošklivé wrappery a spol., věřím vám, že někde se asi skrývat budou, ale přesto prosím o konkrétní příklad.
Formální definice stylu psaní kódu asi neexistuje, vzhledem k rozlehlosti jádra je asi i rozumné, když jsou některé zvyklosti lokální pro subsystém.
Syscally jsou per-arch úmyslně (respektive tabulky syscallů jsou per-arch a občas v nich je nějaký syscall specifický pro danou architekturu), umožňuje to například nezatěžovat se na nových architekturách syscally, které existují pouze z důvodů zpětně kompatibility, nebo optimalizovat číslování syscallů, aby se tabulka lépe cacheovala (opravdu to dává měřitelné zrychlení). VM je skoro celý generický.
(Když už jsme u toho readu, on je opravdu v adresáři fs a má tam být, protože je součástí obecného filesystemového interfacu, jehož místem tento adresář je; jednotlivé filesystémy jsou až v podadresářích)
