Euh, si. Les développeurs du noyau et ceux des programmes en espace utilisateur qui ont directement à faire avec le noyau se parlent, quand même. Ce ne sont pas juste les premiers qui font quelque chose puis les seconds qui suivent. Il y a influence dans les deux sens.
Dans le cas de systemd, il y a notamment eu de nombreux échanges avec les développeurs noyau en charge des cgroups, qui vont conduire prochainement :
– d’une part, à une certaine simplification de l’API des cgroups (l’API actuelle est jugée a posteriori inutilement complexe — notamment, la possibilité d’avoir une hiérarchie indépendante par contrôleur laissera la place à une hiérarchie unique pour tous les contrôleurs) ;
– d’autre part, à ce que systemd masque complètement les cgroups pour ne présenter au reste de l’espace utilisateur qu’une abstraction (à l’avenir, aucun programme à part systemd n’utilisera directement les cgroups, ils devront passer par systemd).
C’est là une évolution notable de tout le dispositif des cgroups, directement influencé par systemd, en tant qu’utilisateur intensif de ceux-ci.
(Avant qu’on me dise que je suis un vieux con réfractaire au changement — ce qui est faux, je ne suis pas vieux —, je précise que je ne vois pas forcément cette évolution d’un mauvais œil.)
[^] # Re: Mon avis personnel
Posté par gouttegd . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 8.
Euh, si. Les développeurs du noyau et ceux des programmes en espace utilisateur qui ont directement à faire avec le noyau se parlent, quand même. Ce ne sont pas juste les premiers qui font quelque chose puis les seconds qui suivent. Il y a influence dans les deux sens.
Dans le cas de systemd, il y a notamment eu de nombreux échanges avec les développeurs noyau en charge des cgroups, qui vont conduire prochainement :
– d’une part, à une certaine simplification de l’API des cgroups (l’API actuelle est jugée a posteriori inutilement complexe — notamment, la possibilité d’avoir une hiérarchie indépendante par contrôleur laissera la place à une hiérarchie unique pour tous les contrôleurs) ;
– d’autre part, à ce que systemd masque complètement les cgroups pour ne présenter au reste de l’espace utilisateur qu’une abstraction (à l’avenir, aucun programme à part systemd n’utilisera directement les cgroups, ils devront passer par systemd).
C’est là une évolution notable de tout le dispositif des cgroups, directement influencé par systemd, en tant qu’utilisateur intensif de ceux-ci.
(Avant qu’on me dise que je suis un vieux con réfractaire au changement — ce qui est faux, je ne suis pas vieux —, je précise que je ne vois pas forcément cette évolution d’un mauvais œil.)