Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
Sauf que bien sur du coup charge au kernel de
a) comprendre que l'on a chargé un nouveau firmware
b) surveiller les étapes de chargement
c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)
Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement...
Posté par Kaane . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 10.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
Sauf que bien sur du coup charge au kernel de
a) comprendre que l'on a chargé un nouveau firmware
b) surveiller les étapes de chargement
c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)
Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.