Je suis sûr que NetBSD a déjà réimplémenter des fonctions car ils se sont rendu compte que ça ne correspondait plus aux usages. (mais comme je ne lis pas les changelog NetBSD et qu'il n'y a pas de patrick_g-*-BSD, je ne peux pas de dire lesquels).
Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.
En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.
Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).
Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)
[^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...
Posté par helkyn . En réponse à la dépêche nftables, successeur d'iptables. Évalué à 2.
Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.
En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.
Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).
Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)