To nie je až tak potrebné ale pri Atomic replace Liva patchingu sa hodí vedieť, čo a ako..
Aj keď podľa mňa nepôjde o
>/usr/include
ale o
/lib/modules/$(uname -r)/build/include/
9 January 2019 at 08:19 AM EST.
Not making it for the Linux 5.0 kernel but continuing to be revised is atomic replace functionality for the livepatching code. The Linux livepatch atomic replace feature allows for cumulative patches and the ability to remove a patch lower in the stack / patch series.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Livepatch-Atomic-Replace
20 January 2019 at 01:28 AM EST. more detail.
Following this work by Akamai, SUSE, and other developers, the atomic replace / cumulative patches series was merged to livepatching for-next this week making it staged material for the upcoming Linux 5.1 cycle.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-Livepatch-Atomic
"Linux" je čisté jádro, takže už z podstaty věci nemá žádná pravidla ohledně distribuce podpůrných souborů. Linuxové distribuce na to mají pravidla jak která. Je pravda, že u Linuxu se jádro občas mění i v rámci jednoho distribučního cyklu, ale to je jenom jinými slovy to, že Linux vydává záplaty a opravy chyb mnohem častěji (a rychleji), než BSD. Mít takové soubory natvrdo v jádře jako jeho nedílnou součást je ale v každém případě dobrý nápad, ať už na Linuxu nebo čemkoli jiném, a docela by mě zajímalo, co konkrétně proti tomu lze mít (kromě "pádného" argumentu, že v Unixu to tak není a tudíž je to samozřejmě špatně). I když je pravda, že drtivá většina uživatelů Linuxu jaderné hlavičky dneska patrně v životě nebude potřebovat instalovat.
Linuxové distribuce na to mají pravidla jak která. Je pravda, že u Linuxu se jádro občas mění i v rámci jednoho distribučního cyklu, ale to je jenom jinými slovy to, že Linux vydává záplaty a opravy chyb mnohem častěji (a rychleji), než BSD.
Právě ta absence pravidel je základ problému, o kterém mluvíme. Jádro se v rámci distribučního cyklu mění, někdy i konfigurace, někdy se novější jádro do starší distribuce backportuje.
Ohledně tvrzení o častosti a rychlosti opravy chyb, tam bych si nebyl tak jistý tím, kdo z toho vyjde lépe. BSD má obecně méně chyb, ale je to také dané tím, že vývoj je mnohem konzervativnější a má menší podporu hardwaru i technologií. Rychlost opravy chyb je naopak na BSD velmi vysoká.
Mít takové soubory natvrdo v jádře jako jeho nedílnou součást je ale v každém případě dobrý nápad, ať už na Linuxu nebo čemkoli jiném, a docela by mě zajímalo, co konkrétně proti tomu lze mít (kromě "pádného" argumentu, že v Unixu to tak není a tudíž je to samozřejmě špatně). I když je pravda, že drtivá většina uživatelů Linuxu jaderné hlavičky dneska patrně v životě nebude potřebovat instalovat.
Není podle mě důvod, aby ty hlavičky byly v /proc a poskytovány běžícím jádrem. Podle mě by bohatě stačilo zavést a dodržovat zvyklost, že s binárním jádrem se distribuují i hlavičkové soubory. Ty pak mohou být na filesystemu a nemusí strašit v /proc.
Právě ta absence pravidel je základ problému, o kterém mluvíme. Jádro se v rámci distribučního cyklu mění, někdy i konfigurace, někdy se novější jádro do starší distribuce backportuje.
Takže jakou konkrétní možnost zavádět taková pravidla má projekt, který spočívá jenom v kernelu a distribuce a dokonce ani organizace souborového systému pod něj nespadá? Pravidla jsou věcí dister, ne linuxu, a všechna hlavní distra tato pravidla samozřejmě mají.
Ohledně tvrzení o častosti a rychlosti opravy chyb, tam bych si nebyl tak jistý tím, kdo z toho vyjde lépe. BSD má obecně méně chyb, ale je to také dané tím, že vývoj je mnohem konzervativnější a má menší podporu hardwaru i technologií. Rychlost opravy chyb je naopak na BSD velmi vysoká
Nejde o to, kdo z toho vyjde lépe, respektive každý z toho vyjde tak, jak to vyplývá z uživatelských nároků. Na Linux jsou kladené mnohem větší nároky, než na BSD stran podpory hardware, funkcí, aplikací, plug&play atd. takže logicky je jádro větší, komplexnější a je vystavené mnohem širší škále situací, konfigurací a bugů, než BSD. Samozřejmě pak potřebuje častější a razantnější aktualizace, stejně jako Windows.
Není podle mě důvod, aby ty hlavičky byly v /proc a poskytovány běžícím jádrem. Podle mě by bohatě stačilo zavést a dodržovat zvyklost, že s binárním jádrem se distribuují i hlavičkové soubory. Ty pak mohou být na filesystemu a nemusí strašit v /proc
Otázka zůstává bez odpovědi. Jakou konkrétně má přítomnost hlaviček v /proc funkční nevýhodu, snad kromě zanedbatelně zvýšených nároků na RAM? Žádnou jmenovatelnou nevýhodu nevidím, naopak vidím velkou výhodou v tom, že to poskytne garanci, že jádro a hlavičky si vzájemně odpovídají. Tato garance dneska neexistuje, a to ani na BSD.