Qu'est-ce qu'une mise à jour du noyau avec "Bump ABI"?
Comme vous pouvez le voir dans le journal des modifications du noyau Linux , il existe des messages de mise à jour du type "Bump ABI - Maverick ABI 28".
Selon = Ubuntu Wiki , ABI est en quelque sorte un pont entre l’espace noyau et les autres modules (mon interprétation).
Une telle mise à jour ajoute-t-elle des fonctionnalités supplémentaires et/ou des corrections de bugs? Devrais-je mettre à niveau mon noyau vers la prochaine version?
NB: Je ne suis pas un expert du noyau - c'est donc basé sur les connaissances et l'expérience acquises.
Une "bosse" ABI ne devrait pas apporter de nouvelles fonctionnalités, même si elle peut "corriger" des bogues dans certains modules/applications qui recherchent une version plus récente de l’ABI. Vous devez toujours installer ces mises à jour, car le maintien de la synchronisation de tous les composants garantit généralement la stabilité et la sécurité.
Tout d’abord, vous ne regardez pas le journal des modifications du noyau Linux. Vous regardez le méta-paquet, qui est un paquet qui dépend du dernier noyau. Vous voulez probablement quelque chose comme: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-image-2.6.35-28-generic/linux-image-2.6.35-28- generic_2.6.35-28.50/journal des modifications
Le but de ce méta-package est de faire passer l'utilisateur à travers ces obstacles ABI.
Je partage le même point de vue que vous sur l’ABI et le noyau. En pratique, une bosse ABI signifie que tous les modules doivent être reconstruits avec le noyau mis à jour.
Ma compréhension est également conforme à Roland, dans la mesure où une bosse ABI ne signifie pas de nouvelles fonctionnalités, mais uniquement des correctifs critiques et des mises à jour de sécurité.
L'ABI est l'interface binaire d'application (à ne pas confondre avec l'API, l'interface de programmation d'application). L'ABI définit les tailles, les signes et les ordres des nombres utilisés par l'application.
Pour être clair, voici un exemple: je veux encoder l’âge d’un bâtiment, exprimé en années. Pour ce faire, je peux utiliser un C unsigned char, qui est un type dont la taille est de 1 octet, et qui peut coder des valeurs de 0 à 255. Supposons maintenant que je découvre que la limite 255 est trop basse car il y a bâtiments qui ont été construits il y a plus de 255 ans. Je peux alors utiliser un C unsigned int, long de 4 octets et pouvant coder des valeurs comprises entre 0 et 65535.
En changeant le type de char à int, je n’ai pas changé la signification sémantique du champ (c’était un âge exprimé en années et il l’est toujours), mais j’ai changé sa taille. Tous les logiciels qui interagissent avec mon application n'ont pas besoin d'être modifiés, mais ils parlent un "langage" différent.
Par conséquent, lorsqu'un noyau change son ABI, cela signifie qu'il a changé de langue, mais aucune fonctionnalité n'a été ajoutée, supprimée ou modifiée. Tous les modules tiers devant interagir avec le noyau doivent être recompilés pour pouvoir parler cette nouvelle langue, mais ils n'ont pas besoin d'être modifiés de quelque manière que ce soit pour fonctionner correctement.