d'accord donc quand on dit que la politique d'ordonnancement est préemptive (SCHED_RR), ca signigie que pour des processus de meme priorité, on verra ces différents processus se partager le CPU ? donc pour SCHEF_FIFO qui est non préemptive, il y a aucun partage du CPU pour les processus de meme priorité ?
d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?
Je cite (vu sur un site) :
"L’ordonnanceur gère la file SCHED_FIFO en utilisant la stratégie non préemptive. Il
choisit d’élire le processus de type SCHED_FIFO le plus prioritaire pour s’exécuter. N’étant
pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"
je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.
tu dis :"je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter" donc le problème de la politique d'ordonnancement SCHED_FIFO c'est que si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY. Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?
oui je suis d'accord avec toi, mais la commande nice -n ne devrait donc pas lancer en meme temps mon second programme car ils sont de priorités différentes or c'est ce qu'il se passe
"car quand je gere les priorités en C avec sched_RR et sched_priority, j'ai bien le premier programme qui se lance en premier puis une fois terminé alors c'est le second qui se lance."
je viens de vérifier et c'est faux ! il lance d'abord un programme puis le second, meme si c'est un sched_RR et qu'ils ont la meme priorité, il exécuté d'abord le premiere programme puis ensuite le second, et je ne sais pas du tout pourquoi
ca marche !!
je ne comprend pas trop comment tu as trouvé la solution, en faite le /dev/loop0p1 désigne bien un périphérique virtuel, et ce périphérique virtuel est lié à la partition sda1?
j'ai déja créer un systeme embarqué avec les commandes :
pour créer une image de 8Mo:
dd if=/dev/zero of=image.img bs=1M count=8
ensuite je créer un systeme de fichier:
/sbin/mkfs.ext2 image.img je monte le fichier image avec la commande mount, puis je place un répertoire boot ou je met mon noyau, je crée un repertoire sbin ou je place mon fichier init, et un repertoire etc avec mon fichier lilo.conf
j'exécute la commande lilo, j'émule avec qemu et ca marche parfaitement, je recois bien "coucou ca va" de mon init. Donc mon noyau a bien créer un systeme de fichier et ensuite lancer mon init.
mon probleme se localise quand je veux partionner l'image. Des que je partitionne avec /sbin/fdisk image.img , je crée une seul partition et ca ne marche plus, bien que je refais la meme démarche :
je créer un systeme de fichier sur ma partition :
/sbin/mkfs.ext2 /dev/mapper/loop0p1 ou /dev/mapper/loop0p1 designe ma partition 1.
ensuite je monte ma partition 1, installe le noyau, le fichier init…
et quand j'émule, ca me met kernel panic impossible de créer le systeme de fichier racine, alors que la demarche est normalement pareil.
as tu une idée du probleme ?
j'avais déja placé cette commande, je te montre mon fichier lilo.conf ca sera peut etre plus simple:
```
boot=/dev/loop0
disk=/dev/loop0
bios=0x80
sectors=63
heads=255
cylinders=1024
image=boot/noyau
label="maintenance"
append="init=/sbin/init"
```
j'ai quand meme mi :
append="root=/dev/sda init=/sbin/init" ou append="root=/dev/sda init=/bin/bash"
mais ca me met toujours la ligne kernel panic impossible de monter le systeme de fichier racine
append="init=/bin/bash" ou append="init=/bin/sh" me retourne bien un shell, et comme tu l'avais pensé, le shell me retourne :
"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0)"
le noyau est incapable de monter le systeme de ficher racine ce qui explique pourquoi il ne trouve pas init, mais je ne comprend pas pourquoi.
alors j'ai choisi une partition en ext2 ce qui devrais marcher normalement. Et mon image n'a qu'une seul partition.
j'ai essayé, lilo ne reconnait pas le paramètre init.
sur ce que j'ai vu sur internet, et qu'il faut passer le paramètre append dans le fichier lilo.conf, ce qui permet de transmettre des parametres au noyau et donc d'indiquer l'emplacement de mon fichier init. Mais ca ne marche toujours pas…
je continue de chercher…
J'ai pris lilo car mon prof me l'a imposé, c'est plus simple à mettre en oeuvre apparemment ;)
c'est tres bizarre car à la fin de son exécution, le noyau est sensé lancer automatiquement le programme init qui se trouve dans /sbin. Or quand je met juste dans mon fichier lilo.conf :
image=boot/noyau
label="noyau-application"
image=boot/noyau
label="noyau-maintenance" ca devrait me lancer automatiquement le programme init, peu importe quel label je choisis à l’amorçage. Or non, quelqu'un à une idée?
[^] # Re: Définir non préemptif…
Posté par cosmoff . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 1.
d'accord donc quand on dit que la politique d'ordonnancement est préemptive (SCHED_RR), ca signigie que pour des processus de meme priorité, on verra ces différents processus se partager le CPU ? donc pour SCHEF_FIFO qui est non préemptive, il y a aucun partage du CPU pour les processus de meme priorité ?
[^] # Re: Définir non préemptif…
Posté par cosmoff . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 2. Dernière modification le 19 janvier 2018 à 13:24.
Merci pour ta réponse.
d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?
Je cite (vu sur un site) :
"L’ordonnanceur gère la file SCHED_FIFO en utilisant la stratégie non préemptive. Il
choisit d’élire le processus de type SCHED_FIFO le plus prioritaire pour s’exécuter. N’étant
pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"
je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.
tu dis :"je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter" donc le problème de la politique d'ordonnancement SCHED_FIFO c'est que si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY. Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?
[^] # Re: oups
Posté par cosmoff . En réponse au message commande nice. Évalué à 1.
Tu as été parfaitement clair !!!
merci beaucoup !
[^] # Re: oups
Posté par cosmoff . En réponse au message commande nice. Évalué à 1.
oui je suis d'accord avec toi, mais la commande nice -n ne devrait donc pas lancer en meme temps mon second programme car ils sont de priorités différentes or c'est ce qu'il se passe
# oups
Posté par cosmoff . En réponse au message commande nice. Évalué à 1.
"car quand je gere les priorités en C avec sched_RR et sched_priority, j'ai bien le premier programme qui se lance en premier puis une fois terminé alors c'est le second qui se lance."
je viens de vérifier et c'est faux ! il lance d'abord un programme puis le second, meme si c'est un sched_RR et qu'ils ont la meme priorité, il exécuté d'abord le premiere programme puis ensuite le second, et je ne sais pas du tout pourquoi
# ca marche
Posté par cosmoff . En réponse au message busybox mettre le clavier en francais. Évalué à 1.
ca marche, pour mettre le clavier en francais il fallait bien modifier le fichier /etc/init.d/rcS :)
[^] # Re: peut-etre parce que ...
Posté par cosmoff . En réponse au message busybox mettre le clavier en francais. Évalué à 1.
mon noyau lance automatiquement le busybox car j'ai ajouté dans mon lilo.conf init=/sbin/busybox.
il faut donc que je crée un script rcS dans le répertoire init.d pour que busybox lance le script rcS.
ce script doit paramétrer mon clavier en Francais et permettre l'écriture sur mon shell c'est bien ca ?
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
ok j'ai compris ;)
en tout cas merci beaucoup NeoX pour ton aide et ton temps, c'est vraiment sympa de partager ton savoir !
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
ok, mais pourquoi mettre root=/dev/sda1 ? car la partition de mon fichier image.img est sur le périphérique loop0p1 ?
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
ca marche !!
je ne comprend pas trop comment tu as trouvé la solution, en faite le /dev/loop0p1 désigne bien un périphérique virtuel, et ce périphérique virtuel est lié à la partition sda1?
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
je t'explique :
j'ai déja créer un systeme embarqué avec les commandes :
pour créer une image de 8Mo:
dd if=/dev/zero of=image.img bs=1M count=8
ensuite je créer un systeme de fichier:
/sbin/mkfs.ext2 image.img
j'exécute la commande lilo, j'émule avec qemu et ca marche parfaitement, je recois bien "coucou ca va" de mon init. Donc mon noyau a bien créer un systeme de fichier et ensuite lancer mon init.
mon probleme se localise quand je veux partionner l'image. Des que je partitionne avec /sbin/fdisk image.img , je crée une seul partition et ca ne marche plus, bien que je refais la meme démarche :
je créer un systeme de fichier sur ma partition :
/sbin/mkfs.ext2 /dev/mapper/loop0p1 ou /dev/mapper/loop0p1 designe ma partition 1.
ensuite je monte ma partition 1, installe le noyau, le fichier init…
et quand j'émule, ca me met kernel panic impossible de créer le systeme de fichier racine, alors que la demarche est normalement pareil.
as tu une idée du probleme ?
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
j'avais déja placé cette commande, je te montre mon fichier lilo.conf ca sera peut etre plus simple:
```
boot=/dev/loop0
disk=/dev/loop0
bios=0x80
sectors=63
heads=255
cylinders=1024
root=/dev/sda
install=menu
prompt
timeout=100
map=boot/map
read-only
image=boot/noyau
label="jeux"
append="init=/sbin/init"
image=boot/noyau
label="maintenance"
append="init=/sbin/init"
```
j'ai quand meme mi :
append="root=/dev/sda init=/sbin/init" ou append="root=/dev/sda init=/bin/bash"
mais ca me met toujours la ligne kernel panic impossible de monter le systeme de fichier racine
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
alors j'ai crée une image de base, donc dans mon image je n'ai qu'un repertoire boot, un etc et sbin, je ne peux donc pas faire ta commande :(
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
append="init=/bin/bash" ou append="init=/bin/sh" me retourne bien un shell, et comme tu l'avais pensé, le shell me retourne :
"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0)"
le noyau est incapable de monter le systeme de ficher racine ce qui explique pourquoi il ne trouve pas init, mais je ne comprend pas pourquoi.
alors j'ai choisi une partition en ext2 ce qui devrais marcher normalement. Et mon image n'a qu'une seul partition.
[^] # Re: reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
j'ai essayé, lilo ne reconnait pas le paramètre init.
sur ce que j'ai vu sur internet, et qu'il faut passer le paramètre append dans le fichier lilo.conf, ce qui permet de transmettre des parametres au noyau et donc d'indiquer l'emplacement de mon fichier init. Mais ca ne marche toujours pas…
je continue de chercher…
J'ai pris lilo car mon prof me l'a imposé, c'est plus simple à mettre en oeuvre apparemment ;)
# reponse
Posté par cosmoff . En réponse au message créer une image avec 2 options d’amorçage. Évalué à 1.
merci de m'avoir répondu.
j'ai essayé la ligne
append="init=/sbin/init"
mais aussi
append="init=sbin/init"
et
append="sbin/init"
mais non mon noyau ne lance rien :(
c'est tres bizarre car à la fin de son exécution, le noyau est sensé lancer automatiquement le programme init qui se trouve dans /sbin. Or quand je met juste dans mon fichier lilo.conf :
image=boot/noyau
label="noyau-application"
image=boot/noyau
label="noyau-maintenance"