Alors je reprends lentement.
Phase 1:
Renault déclare dans son post qu'il est normal que l'init utilise des fonctionnalités spécifiques du noyeau, vu que c'ets un composant proche du noyau
Phase 2:
Je répond que l'init n'est pas plus proche du noyau que n'importe quel autre processus qui tourne en root.
Phase 3:
Renault surrenchérit en disant que l'init est bien proche du noyau car c'est le noyau qui fournit les abstractions qui permettent de gérer entre autres, porcessus et cgroups
Phase 4:
Je signale tout d'abord que le noyau ne fournit pas d'abstractions (je reviens dessus dans un instant) mais des interfaces et que le noyau fournissant de façon générale toute les interfaces, dire qu'un processus est privilégié parcequ'il a besoin d'interragir avec le noyau est pas franchement discriminant.
Je reste sur ma lancé, l'init processus comme les autres qui n'a ni plus ni moins de raisons que les autres d'utiliser des fonctionnalités spécifiques de Linux.
C'est sur ce post là que tu interviens. Je n'ai pas encore commencé à taper sur systemd (ce que je ferai plus tard, suites aux provocations de Barret Michel)
Tout ce que j'ai dit pour l'instant c'est que au niveau des interractions avec le kernel, l'init est un processus root comme les autres.
Maintenant ton propos :
Ce que je relève, cette abstraction dans le cas /proc est faite directement par le kernel et pas du tout par l'init
a) je n'ai jamais dit que /proc était fait par l'init. J'ai même dit à plusieurs reprise que l'init n'avait pas plus de prise sur les abstractions que n'importe quel processus root. Si l'init était nécessairement à l'origine du /proc, je me serais abstenu.
b) L'abstraction n'est pas faite directement par le kernel. Le kernel (si on a les bonnes options de compilation) peut, si on lui en fait la demande créer une interface secondaire pour le suivi des processus, réserver une zone mémoire, et créer une abstraction filesystem sous forme de pseudo-device mappé en ram et présentée en userland. Dire que cet abstraction est fournie directement par le kernel c'est comme de dire que l'abstraction /media/vcdrom de montage d'une image iso est fournie directement par le kernel. A ce compte là tout est fourni directement par le kernel. Ce que l'on considère directement fourni par le kernel se sont les interfaces, c'est à dire des fonctions userland pour envoyer des commandes au kernel et recevoir ses réponses sans passer par des drivers. Et niveau drivers /proc est plutôt chargé (ram mapping + pseudoFS + moniteur).
Et ça m'inspire surtout "so what ?". Le kernel aussi, et alors ?
La gestion de processus par le kernel, à savoir l'attribution de PID, l'ordonnancement, l'attribution mémoire et son mapping, présentation des appels systèmes d'attentes etc, n'a rien à voir avec la gestion userland des processus. Une fois de plus je ne fais que répondre à Renault qui me dit que l'init est proche du noyau car il participe à la gestion des processus. Je ne fais que lui répondre qu'il ne participe pas plus à la gestion des processus que d'autres processus lancés en root qu'on va avoir du mal à considérer comme proche du noyau (psDoom franchement...)
Je comprends bien que tu n'aimes pas systemd pour des raisons qui te sont propres, mais il faut un minimum rester cohérent dans les arguments.
Je comprends que tu n'aimes pas les gens qui n'aiment pas systemd, mais il faut lire un minimum les threads auquels tu réponds. A l'instant ou tu réponds dans le thread je n'ai pas dit un mot sur systemd ni spécifiquement en tant qu'init, ni généralement en tant que framework. La seule et unique chose que je défends est que vis à vis des interractions avec le noyau, l'init a exactement les mêmes accès et besoins que n'importe quel autre processus.
Deuxièmement quand on attaque une personne sur la cohérence de ses arguments, il faut un minimum vérifier que les arguments qu'on lui prête sont véritables.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Kaane . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 6. Dernière modification le 26 septembre 2014 à 22:36.
Alors je reprends lentement.
Phase 1:
Renault déclare dans son post qu'il est normal que l'init utilise des fonctionnalités spécifiques du noyeau, vu que c'ets un composant proche du noyau
Phase 2:
Je répond que l'init n'est pas plus proche du noyau que n'importe quel autre processus qui tourne en root.
Phase 3:
Renault surrenchérit en disant que l'init est bien proche du noyau car c'est le noyau qui fournit les abstractions qui permettent de gérer entre autres, porcessus et cgroups
Phase 4:
Je signale tout d'abord que le noyau ne fournit pas d'abstractions (je reviens dessus dans un instant) mais des interfaces et que le noyau fournissant de façon générale toute les interfaces, dire qu'un processus est privilégié parcequ'il a besoin d'interragir avec le noyau est pas franchement discriminant.
Je reste sur ma lancé, l'init processus comme les autres qui n'a ni plus ni moins de raisons que les autres d'utiliser des fonctionnalités spécifiques de Linux.
C'est sur ce post là que tu interviens. Je n'ai pas encore commencé à taper sur systemd (ce que je ferai plus tard, suites aux provocations de Barret Michel)
Tout ce que j'ai dit pour l'instant c'est que au niveau des interractions avec le kernel, l'init est un processus root comme les autres.
Maintenant ton propos :
a) je n'ai jamais dit que /proc était fait par l'init. J'ai même dit à plusieurs reprise que l'init n'avait pas plus de prise sur les abstractions que n'importe quel processus root. Si l'init était nécessairement à l'origine du /proc, je me serais abstenu.
b) L'abstraction n'est pas faite directement par le kernel. Le kernel (si on a les bonnes options de compilation) peut, si on lui en fait la demande créer une interface secondaire pour le suivi des processus, réserver une zone mémoire, et créer une abstraction filesystem sous forme de pseudo-device mappé en ram et présentée en userland. Dire que cet abstraction est fournie directement par le kernel c'est comme de dire que l'abstraction /media/vcdrom de montage d'une image iso est fournie directement par le kernel. A ce compte là tout est fourni directement par le kernel. Ce que l'on considère directement fourni par le kernel se sont les interfaces, c'est à dire des fonctions userland pour envoyer des commandes au kernel et recevoir ses réponses sans passer par des drivers. Et niveau drivers /proc est plutôt chargé (ram mapping + pseudoFS + moniteur).
La gestion de processus par le kernel, à savoir l'attribution de PID, l'ordonnancement, l'attribution mémoire et son mapping, présentation des appels systèmes d'attentes etc, n'a rien à voir avec la gestion userland des processus. Une fois de plus je ne fais que répondre à Renault qui me dit que l'init est proche du noyau car il participe à la gestion des processus. Je ne fais que lui répondre qu'il ne participe pas plus à la gestion des processus que d'autres processus lancés en root qu'on va avoir du mal à considérer comme proche du noyau (psDoom franchement...)
Je comprends que tu n'aimes pas les gens qui n'aiment pas systemd, mais il faut lire un minimum les threads auquels tu réponds. A l'instant ou tu réponds dans le thread je n'ai pas dit un mot sur systemd ni spécifiquement en tant qu'init, ni généralement en tant que framework. La seule et unique chose que je défends est que vis à vis des interractions avec le noyau, l'init a exactement les mêmes accès et besoins que n'importe quel autre processus.
Deuxièmement quand on attaque une personne sur la cohérence de ses arguments, il faut un minimum vérifier que les arguments qu'on lui prête sont véritables.