Apparement c'est fort similaire à ce qui se fait dans RHEL. L'idée c'est que l'organisation qui maintient la distribution garantit la « stabilité » de certains symboles. Évidemment, ça marche qu'avec un kernel que l'organisation contrôle et tu vas pas pouvoir magiquement installer le dernier linux-next de kernel.org sans tout péter.
Après, au moins dans RHEL, il y a des mécanismes intégrés à rpmbuild pour éviter que les gens ne dépendent par erreur de symboles dont la stabilité n'est pas garantie. En pratique, les symboles dont la stabilité est garantie sont groupés en kABIs (genre tous les trucs liés au réseau,...) pour lesquels une signature est générée. Le kernel satisfait donc des dépendances telles que "kernel(rhel5_net_sunrpc_ga) = 24164573208ac3a8706912194cb786857d2222d6". Quand tu buildes un modules pour ce kernel, rpmbuild va examiner tous les symboles dont il dépend et les ajouter en dépendances au niveau RPM, soit via les kABIs explicités (et du coup ça marche pour tous les kernels dont la signature du kABI correspondant ne change pas), soit en explicitant le dépendance sur le symbole spécifique et sa signature s'il ne fait pas partie d'un kABI « supporté » (et du coup, le RPM du module va pas s'installer parce que la dépendance est pas satisfaisable puisque le RPM du kernel ne la satisfait pas explicitement).
[^] # Re: ça marche comment?
Posté par Krunch (courriel, site web personnel) . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à 10.
C'est décrit par là http://drivers.suse.com/doc/SolidDriver/How_It_Works.html#how-it-works
Apparement c'est fort similaire à ce qui se fait dans RHEL. L'idée c'est que l'organisation qui maintient la distribution garantit la « stabilité » de certains symboles. Évidemment, ça marche qu'avec un kernel que l'organisation contrôle et tu vas pas pouvoir magiquement installer le dernier linux-next de kernel.org sans tout péter.
Après, au moins dans RHEL, il y a des mécanismes intégrés à rpmbuild pour éviter que les gens ne dépendent par erreur de symboles dont la stabilité n'est pas garantie. En pratique, les symboles dont la stabilité est garantie sont groupés en kABIs (genre tous les trucs liés au réseau,...) pour lesquels une signature est générée. Le kernel satisfait donc des dépendances telles que "kernel(rhel5_net_sunrpc_ga) = 24164573208ac3a8706912194cb786857d2222d6". Quand tu buildes un modules pour ce kernel, rpmbuild va examiner tous les symboles dont il dépend et les ajouter en dépendances au niveau RPM, soit via les kABIs explicités (et du coup ça marche pour tous les kernels dont la signature du kABI correspondant ne change pas), soit en explicitant le dépendance sur le symbole spécifique et sa signature s'il ne fait pas partie d'un kABI « supporté » (et du coup, le RPM du module va pas s'installer parce que la dépendance est pas satisfaisable puisque le RPM du kernel ne la satisfait pas explicitement).
Pour RHEL5 c'est détaillé (sans doute plus clairement que mon pavé ci-dessus) dans http://driverupdateprogram.com/presentations/DriverUpdateProgramTechnical.pdf
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.