Nesze neked RHEL 7 stabil kernel

Azt hiszem el kell felejtenem, hogy a Red Hat nem nyulkal bele olyan szinten a kernelbe mint a SUSE SP valtaskor ... a Red Hat rosszabb lett most a 7.1 -> 7.2 attereskor.

Elkezdtuk a belso teszteket a 7.2 temogatott-e kerdes megvalaszolasahoz es hat az elso hiba, hogy nem talalhato a "ktime_get_ts" funkcio ... mert mar ktime_get_ts64 neven ismerheto meg...

Kimondottan nem lenne gond egy ilyen ... de ugye a Red Hat elviekben nem valtoztat elesen foverzion belul ...
Ennek ellenere ami mukodott 3.10.0-229 (7.1) kernel alatt az most 3.10.0-327 (7.2) kernel alatt nem mukodik a kernel valtozasok miatt ... mintha csak SuSe lenne ahol egy SP valtas kernel ugras, glibc valtas is van ...

Igen tudom, emiatt kell changelogot olvasni ...

( dikki | 2016. 09. 12., h – 21:52 )

"ahol egy SP valtas kernel ugras, glibc valtas is van"
ahol egy SP valtas kernel ugras, glibc valtas is lehet

( sibike | 2016. 09. 12., h – 21:56 )

Elsőre rávágtam volna, hogy a Red Hat sosem garantált stabil kernel api-t minor release-ek között, de mint kiderült meghatározza azokat a fv hívásokat, amikre a fejlesztők használhathnak, és biztos nem változnak minor release-ek között. Ezeket tartalmazza a kernel-abi-whitelists csomag. Bővebben:

https://access.redhat.com/solutions/444773

Még ellenőrizni is tudod a kernel modulodat, hogy milyen nem stabil hívásokat tartalmaz:

http://kozlex.blogspot.hu/2015/05/listing-missed-whitelist-kernel-modul…

( JoeBlackJoe | 2016. 09. 14., sze – 18:48 )

Szóval azért nem "stabil" a kernel mert valami Third-party softwaret nem fejlesztenek?

Gondolom van egy sajat szoftveruk, ami hasznalja ezt a kernel API-t. Mivel a Red Hat update eltavolitotta ezt a kernel API-t, igy a sajat szoftveruk nem megy.
Nme 3rd partyrol van szo, a ktime_get_ts az kernel API. Es ha egyszercsak eltavolitasra kerul, akkor bizony a kernel API az, ami instabil.