Linuxové hlavičkové soubory by mohly být dostupné přes /proc/kheaders.gz

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/$(u­name -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

Není to po prvé, co mám pocit, že se Google rozhodl Linux rozložit zevnitř.
Linux bohužel nepřevzal dost "zdravých" věcí z Unixu, ale zase tím získal jiné výhody.
Teď mám pocit, že se někdy snaží svoji filozofii revidovat, ale to může vést jen k tomu, že Linux získá kumulativně všechny nevýhody.

Mám takový pocit, že co je na unixu "zdravé" by člověk spočítal na prstech jedné ruky.

Mít příslušné hlavičkové soubory "natvrdo" spojené s jádrem mi naopak připadá jako silně žádoucí.

Což se u BSD nerozejde, protože jedna verze systému má jedno jádro, jedny hlavičky.
Linux si na toto nezavedl dobrá pravidla, takže se hledá ohejbák.

"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.