Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS BSD *BSD et numéros de version

*BSD et numéros de version

11 réponses
Avatar
Philippe
Bonjour à tous!

Venant de la banquise, je cherche à comprendre le signification des
numéros de version sur les != BSD. Sachant qu'il ont tous leur origine
à peut près à la même époque( mis à part OpenBSD ) pour qui ont ils des
numéros de version si différents? Cela indique t'il l'état advancement
des != projets les uns par rapport aux autres ou s'agit il de politiques
de numérotation différentes?

Si quelqu'un peut m'éclairer, je lui en serait grés! :-)

Philippe from ice.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
manu
Philippe wrote:

Venant de la banquise, je cherche à comprendre le signification des
numéros de version sur les != BSD. Sachant qu'il ont tous leur origine
à peut près à la même époque( mis à part OpenBSD ) pour qui ont ils des
numéros de version si différents? Cela indique t'il l'état advancement
des != projets les uns par rapport aux autres ou s'agit il de politiques
de numérotation différentes?


Deuxieme solution.

NetBSD a fait 0.8, 0.9, puis 1.0. Ensuite, 1.1, 1.2 ... 1.6. Le numero
de majeur n'a jamais été re-incrementé, ce qu'il fait qu'il ne sert plus
à rien. NetBSD 1.6 etait la 9eme release majeure de NetBSD, si je compte
bien.

Le projet NetBSD a décidé de reformer sa numérotation histoire de ne pas
laisser un numero inutilisé. Le prochain NetBSD (qui aurait pu être 1.7)
sera donc 2.0. On s'est dit que vu le nombre de nouveautés (scheduler
activation, SMP sur i386...), si on ne passe pas à 2.0 cette fois là, on
n'aura jamais de meilleure opportunité de le faire.

OpenBSD a commencé à 2.0, (Explication possible: OpenBSD 1.x c'est
NetBSD). Il y a eu 2.0, 2.1, 2.2... jusqu'à 2.9, puis 3.0, 3.1, etc...
OpenBSD 3.3 est donc la 13eme release majeure d'OpenBSD.

Coté FreeBSD, le numero de majeur est incrémenté pour chaque release
majeure, c'est encore la numerotation la plus logique des 3. Donc,
FreeBSD 1.0, 2.0, 3.0, 4.0, 5.0

En plus de cela, NetBSD et FreeBSD font des releases mineures. Exemple
pour NetBSD 1.5: 1.5.1, 1.5.2, 1.5.3. Exemple pour FreeBSD 4.0: 4.1,
4.2, 4.3... 4.8

--
Emmanuel Dreyfus


Avatar
Hubert Tournier
Bonjour,

Coté FreeBSD, le numero de majeur est incrémenté pour chaque release
majeure, c'est encore la numerotation la plus logique des 3. Donc,
FreeBSD 1.0, 2.0, 3.0, 4.0, 5.0


Encore que le marketing soit parfois entré en ligne de compte (cf.
http://www.freebsd.org/news/sou1999.html, § Release numbering).

Bien cordialement,
--
La collection Le Cadran Bleu : http://www.cadranbleu.com/

Avatar
pornin
According to Emmanuel Dreyfus :
Coté FreeBSD, le numero de majeur est incrémenté pour chaque release
majeure, c'est encore la numerotation la plus logique des 3. Donc,
FreeBSD 1.0, 2.0, 3.0, 4.0, 5.0


Un autre point lié est celui des numéros de version de la libc. Dans le
format ELF (ainsi que dans d'autres formats), une bibliothèque partagée
(un "shared object") a un numéro "majeur" qui l'identifie avec son nom.
Quand un binaire a besoin d'une bibliothèque, c'est marqué dedans ;
par exemple, sur ma machine de bureau (un FreeBSD 4.8), /usr/bin/grep
demande "libc.so.4", "libz.so.2" et "libgnuregex.so.2". Le linker
dynamique cherchera et trouvera ces bibliothèques, sous ce nom (dans
/usr/lib/ dans le cas de ma machine).

Une conséquence est que si on met à jour une de ces bibliothèques, et
qu'on garde le même numéro de version, alors la nouvelle bibliothèque
doit être compatible au niveau binaire avec l'ancienne : en effet, les
binaires liés avec l'ancienne doivent continuer de pouvoir fonctionner
avec la nouvelle. Si la nouvelle bibliothèque n'assure pas cette
compatibilité ascendante, elle doit être installée avec un numéro de
version différent ; ceci permet de l'installer à côté de l'ancienne,
pas à la place, et de pouvoir continuer à lancer des binaires liés à
l'ancienne version.

Il est facile de conserver la compatibilité ascendante quand on ne
fait que rajouter des fonctions, mais des fois il faut casser. Des
exemples typiques sont quand on doit augmenter la taille d'un type
(par exemple une fonction qui prenait un argument sur 32 bits mais
doit passer à 64 bits). L'usage sous FreeBSD est de faire coïncider le
numéro de version majeure de la libc avec celui de l'OS en général :
FreeBSD-3.x a une libc.so.3, FreeBSD-4.x a une libc.so.4, etc... Donc,
d'une certaine manière, FreeBSD change de numéro de version majeure
quand les changements de l'OS impliquent une incompatibilité binaire
ascendante de la libc.


NetBSD et OpenBSD on pris une voie différente, en changeant assez
fréquemment le numéro de version majeure de la libc. NetBSD 1.6.1
a une "libc.so.12". OpenBSD 3.3 a une "libc.so.29".


Linux et Solaris, par comparaison, ont aussi pris une voie différente :
ils s'assurent que la compatibilité ascendante est assurée pour les
siècles des siècles. Toutes les libc de Linux sont en libc.so.6, et
sous Solaris c'est libc.so.1 (là je dis ça de mémoire, je peux me tromper).
L'idée est qu'ils ont étendu le format ELF pour rajouter du "symbol
versioning" : ça permet de faire cohabiter plusieurs fonctions de même
nom dans la même bibliothèque partagée. Ladite bibliothèque contient des
informations en plus qui permettent de retrouver qui a besoin de quoi.
D'une certaine manière, c'est comme le coup des changements de version
majeure, sauf que c'est géré en interne dans la bibliothèque, et
séparément pour chaque fonction.

Pour le moment, je ne crois pas que les *BSD usuels (FreeBSD, NetBSD et
OpenBSD) aient prévu d'adopter ce schéma, mais comme tout ce petit monde
utilise les GNU binutils, ça pourrait bien venir tôt ou tard. De même
qu'OpenBSD passe timidement à ELF, pour un peu les mêmes raisons.


En résumé, dans le cas de FreeBSD, on discerne une association fine
entre le numéro de version de l'OS (qui est essentiellement un concept
de marketing) et le numéro de version de la libc, qui est une donnée
technique indispensable au bon fonctionnement. On ne voit pas la même
association dans le cas de NetBSD et OpenBSD.


--Thomas Pornin

Avatar
manu
Thomas Pornin wrote:

En résumé, dans le cas de FreeBSD, on discerne une association fine
entre le numéro de version de l'OS (qui est essentiellement un concept
de marketing) et le numéro de version de la libc, qui est une donnée
technique indispensable au bon fonctionnement. On ne voit pas la même
association dans le cas de NetBSD et OpenBSD.


"Donnée technique indispensable", est ce que tu n'y vas pas un peu fort?
J'avoue que sous NetBSD je n'ai jamais eu à m'interesser aux numeros de
version de la libc. La compatibilité ascendante marche suffisament bien
pour que cette donnée ne m'aparaisse pas comme indispensable.

--
Emmanuel Dreyfus


Avatar
pornin
According to Emmanuel Dreyfus :
"Donnée technique indispensable", est ce que tu n'y vas pas un peu fort?


Euh non, j'ai dit exactement ce que je voulais dire. Mais je peux
clarifier : une "donnée technique indispensable", c'est une valeur
qui doit être fixée dans le logiciel (dans son ensemble) pour que
le logiciel (dans son ensemble) fonctionne comme il se doit. Que
l'utilisateur soit au courant ou pas n'entre pas en ligne de compte.
Ici, la libc _doit_ avoir un numéro de version majeure, et les
(non-)changements de numéro de version doivent suivre la règle de
compatibilité binaire dont je causais (en cas d'incompatibilité
ascendante, le numéro doit changer), sinon les applications ne se
lancent pas. Ce numéro de version est une donnée, elle est technique
(_d'ailleurs_, l'utilisateur n'en tient que rarement compte, ce qui
prouve bien qu'elle est destinée au logiciel et pas à l'utilisateur), et
elle est indispensable (il faut bien qu'il y ait un tel numéro, sinon
les applications ne se lancent pas).

Par opposition, le numéro de version du système d'exploitation, comme
"1.6.1" dans le cas de NetBSD, est une "donnée sociale optionnelle" :
c'est certes une donnée inscrite dans le logiciel (on l'obtient avec la
commande "uname") mais elle est destinée à l'utilisateur, et si on la
change les applications s'en balancent complètement (à part peut-être
une ou deux applications bugguées qui récupèrent ce numéro, et tentent
de finasser avec, et se vautrent -- mais ça tient plus du bug que
d'autre chose).


--Thomas Pornin

Avatar
pornin
According to Manuel Bouyer :
Les changements incompatibles d'interfaces sont maintenant
traites par des renomage de symboles.
Par exemple, quand fstat a change, le symbole fstat de la libc utilise
toujours l'ancienne interface, et la nouvelle a ete apellee __fstat13.
/usr/include/sys/stat.h contient un alias pour que les programmes
compiles utilisent __fstat13 et non pas fstat:
int fstat __P((int, struct stat *)) __RENAME(__fstat13);


Ceci est typiquement du "symbol versioning" géré au niveau source, donc
implémenté par le compilateur C (dont fait partie le préprocesseur, qui
fait probablement une bonne partie du boulot de renommage). Le "symbol
versioning" de Linux et Solaris est géré par le linker (le statique,
pour produire les entrées de tables de symbole qui vont bien, et le
dynamique, pour retrouver les bons morceaux lors de l'exécution).

Si NetBSD a choisi cette solution, alors il est bien possible qu'ils
résistent longtemps au "symbol versioning" du linker.


--Thomas Pornin

Avatar
Manuel Bouyer
Thomas Pornin wrote:
According to Manuel Bouyer :
Les changements incompatibles d'interfaces sont maintenant
traites par des renomage de symboles.
Par exemple, quand fstat a change, le symbole fstat de la libc utilise
toujours l'ancienne interface, et la nouvelle a ete apellee __fstat13.
/usr/include/sys/stat.h contient un alias pour que les programmes
compiles utilisent __fstat13 et non pas fstat:
int fstat __P((int, struct stat *)) __RENAME(__fstat13);


Ceci est typiquement du "symbol versioning" géré au niveau source, donc
implémenté par le compilateur C (dont fait partie le préprocesseur, qui
fait probablement une bonne partie du boulot de renommage). Le "symbol
versioning" de Linux et Solaris est géré par le linker (le statique,
pour produire les entrées de tables de symbole qui vont bien, et le
dynamique, pour retrouver les bons morceaux lors de l'exécution).

Si NetBSD a choisi cette solution, alors il est bien possible qu'ils
résistent longtemps au "symbol versioning" du linker.


C'est pas trop mon domaine, mais je pense que cette solution a ete choisie
parce qu'a l'epoque presque toute les plateformes etaient a.out.
En plus, je soupsonne que le faire comme ca fait moins de boulot pour le
linker, mais je peux me tromper.

--
Manuel Bouyer
NetBSD: 24 ans d'experience feront toujours la difference
--


Avatar
pornin
According to Manuel Bouyer :
C'est pas trop mon domaine, mais je pense que cette solution a ete choisie
parce qu'a l'epoque presque toute les plateformes etaient a.out.


Par ailleurs, le "symbol versioning" ELF n'est pas standard. ELF prévoit
des possibilités d'extensions, Sun a rajouté les siennes, GNU a fait
de même, mais il n'existe (à ma connaissance) aucun document "officiel"
qui décrive ces extensions. Je ne sais pas non plus si Sun et GNU ont
fait les mêmes extensions.


En plus, je soupsonne que le faire comme ca fait moins de boulot pour le
linker, mais je peux me tromper.


Ça oui. Le linker (le statique comme le dynamique) ne voit plus que des
liens tout bêtes vers __fstat13 et n'a pas à analyser des versions.
Donc, potentiellement, la méthode NetBSD permet un lancement plus rapide
des exécutables dynamiques. En revanche, elle rend l'utilisation
d'autres langages de programmation un peu plus difficile : l'information
"fstat() est pour le moment un lien vers __fstat13()" n'est disponible
que dans un header C avec une syntaxe C.


--Thomas Pornin

Avatar
Manuel Bouyer
Xavier wrote:
Thomas Pornin wrote:

l'information "fstat() est pour le moment un lien vers __fstat13()" n'est
disponible que dans un header C avec une syntaxe C.


Et un compilateur GNU, parce que suis pas certain que l'extension RENAME
soit ANSI...


En fait le renomage se fait par un stub assembleur. Il faut que le
compilateur comprenne __asm__(). Dans certains language c'est peut-etre
meme pas possible ...

--
Manuel Bouyer
NetBSD: 24 ans d'experience feront toujours la difference
--


Avatar
manu
Thomas Pornin wrote:

[numéro de version de la libc]
Ce numéro de version est une donnée, elle est technique
(_d'ailleurs_, l'utilisateur n'en tient que rarement compte, ce qui
prouve bien qu'elle est destinée au logiciel et pas à l'utilisateur),


Va dire ca aux usagers de Linux! ;o)

et elle est indispensable (il faut bien qu'il y ait un tel numéro, sinon
les applications ne se lancent pas).


A ce compte, il y a beaucoup d'autres données techniques indispensables
dans un système UNIX...

--
Emmanuel Dreyfus


1 2