systeme POSIX - Page 2

au debut ce sera presque pas POSIX,il devrit y avoir une trentaine seulement d'appel systeme
avec:-un shell limite(tres)
-gestion de processus
-gestion de la memoire (au debut seulement sur un fichier de ~60Ko)
-systeme de fichiers
le tout en serveurs avec un micronoyau

alors pour ceux qui veulent du graphisme ce ne sera pas pour tout de suite

ben bon courage mon gars

B

(Sinon, Linux et d'autres OS libres, surtout NetBSD, auraient été certifié Posix depuis belle lurette...)

C'est bien connu

chez pas ou vous avez vu du posix sous linux ? sous le tapis ptet mais moi je le cherche encore

seul les "vrai" unix (BSD like ou System V like) peuvent etre qualifié de posix, ainsi que d'autre OS type unix :

BeOS, QNX,.... sont certifié POSIX

godzil :
chez pas ou vous avez vu du posix sous linux ? sous le tapis ptet mais moi je le cherche encore

(je parlait du tapis ou il est caché bien sur )

B

Reaprend tes classique, tu verra que BeOS et QNX sont certifié POSIX

A

est-ce que l'on pourrait me dire ce qui ne va pas (je sais ,je vais surement me ridiculiser!):

struct PROCESS {
	int parent;
	int time_left;
	struct {
		int multithread:1,numthread:1,state:3;
	} flags;
	char name[16];
	struct s_msg *msg;
	struct CTX ctxtab[2];
};
...
struct PROCESS *proc;
...
proc->name=("MCP"); 
proc->flags={0,0,RUNNING};

C'est pas très clair... Déjà, est-ce que tu fais une distinction process/thread? (sur TI, ça n'a à peu près aucun sens sauf tu veux faire de la libération auto de handles/FILE*, mais je pose la question au cas où)
Ensuite, qu'est-ce que tu entends par CTX? Sauvegarde des registres? De la pile? (si c'est le cas, comment tu gère la sauvegarde des piles?) Et au fait, pkoi est-ce qu'il y a 2 CTX? Et tu as une priorité pour tes processus?
Est-ce que ton task switcher aura une gestion des verrous, ou est-ce que tu vas te débrouiller avec l'instruction TAS ou un trap quelconque ?

1/je fais une distinction process/thread
2/CTX :structure associee au contexte (registres,PC)
3/pour les piles,je suis en train d'y reflechir ,mais a priori, ce serait une pile privee par processus
4/multithreading : 2 thread pourraient etre associe a un processus
5/pour le task switcher , ce sera avec une auto-interruption(a priori la 1)

poruquoi est ce qu'il me met une erreur pour les deux dernieres lignes???

1) et tu vas t'en servir pour quoi faire?
2) ok, mais il faudra aussi stocker d'autres choses, comme la taille/le handle de la pile...
3) par thread, même, ça pourrait être utile
4) a) pourquoi 2 maximum? b) et pourquoi pas juste 1?
5) oui évidemment (et d'ailleurs tu pourrais réfléchir à quel niveau d'interruption tu vas choisir, la 5 peut être plus intéressante...), mais ma question portait sur la gestion des sémaphores et autres verrous : est-ce que tu intégreras un support spécial dans ton task switcher ou est-ce que ce sera "démerdez-vous" ?

6) parce que c'est pas du (GNU-)C valide Tu peux essayer :
proc->name=(char[16])"MCP"
mais je ne suis pas sûr du tout que ça marche, de toute façon The Right Thing serait de faire strcpy(proc->name,"MCP"); (et si tu tiens à padder avec des 0, tu peux utiliser strncpy, ou encore prendre une structure intermédiaire du style *(struct foo{char bar[16];}*)proc->name=(struct foo){"MCP"} mais c'est très gore)
Pour la deuxième, (struct flags){0,0,RUNNING} marche peut-être (à moins que ça foire avec les bitfields).

6/ca y est, ca marche
1/pour faire tourner 2 thread/ process
2/c'est possible (de toute facons , ces informations ne sont pas encore statiques)
3/effectivement
4/a/parce que 4 ca ferait beaucoup (puissance de 2)
4/b/pour le fun et le multitache
5/le systeme devrait etre totalement preemptif : il ne devrait probablement pas y avoir de verrous,
mais il y aura surement une fonction genre "nice"
et en plus chaque appel systeme bloquant provoquera l' appel du task-switcher

1) je t'en demandais quel est l'intérêt par rapport à avoir une tâche par processus (et donc d'avoir 2 processus au lieu d'un)
2) c'est quand même le genre de chose ultra-basique auxquelles il vaut mieux penser avant, par exemple comment tu vas gérer le fait qu'il faut allouer toujours un peu plus de mémoire pour la pile que ce qu'il y avait au dernier task switching?
4) cf 1) 5)

le systeme devrait etre totalement preemptif : il ne devrait probablement pas y avoir de verrous

oui, bien sûr, les verrous sont plutôt pour les systèmes coopératifs D'ailleurs chacun sait que dans n'importe quel OS moderne, on n'utilise plus les sémaphores : ça date de la préhistoire

1/l'interet c'est de pouvoir ecrire des programmes avec 2 threads
exemple:un traitement de texte avec :1 thread pour l'affichage
1 thread pour les operations sur le fichier lu
cela dit il y a probablement d'autres exemples meilleurs.
2/ j'avais pense a allouer une pile de taille fixe (mais c'est peut-etre pas tres bon comme algorithme
5/???

1) et si je fais deux process, un d'affichage, un pour les opérations sur les fichier lu? (avec éventuellement un regroupement via un champ supplémentaire pour montrer qu'ils ont la même origine)
2) peut-être pas, parce qu'il faudra aussi choisir la taille de la pile. une meilleure solution serait de coopérer avec le compilo pour lui faire générer des appels vers une fonction Resize() lorsqu'elle a besoin de bcp de mémoire d'un coup.
5) tu as d'autant plus besoin de verrous que tu fais un système préemptif : tu as toujours besoin d'une synchronisation entre threads, ou encore besoin d'accéder à des ressources partagées (par ex, deux threads qui se partagent la lecture des événements de l'application)

pour les ressources partagees (ecran,clavier,...) ,je pense utiliser un systeme avec des serveurs
cad:un serveur qui s'occupe de l'affichage, et les autres processus qui communiqueront avec.
ex:le processus principal d'un jeu va demander au serveur d'affichage d'afficher ce qu'il veut en envoyant des messages qui seront stockes dans une file ,et lorsqu'elle sera pleine, le task-switcher sera appele pour que le serveur d'affichage vide la file,etc...

2/c'est une idee

1) j'ai toujours pas compris pkoi tu voulais absolument faire plusieurs thread par process
5) les ressources partagées peuvent être internes à l'application.

1/c'est pas obligatoire, mais ca pourrait apporter plus de souplesse
(changement de contexte plus rapide entre thread qu'entre process)
5/pour ca ,j'ai pas trop de solutions

1) et quelle nuance tu apporterais entre le changement de thread et le changement de process?
5) rassure toi c pas très compliqué à implémenter, mais ça peut aider d'y avoir pensé

5/je m'en doute bien
1/comme le systeme devrait etre plus ou moins posix il y aura les descripteurs de fichiers qui seront attaches aux processus,et pas aux thread(ie:chaque thread d'un processus pourra ecrire et lire dans un fichier attache au processus auxquels ils appartiennent,et pas a un fichier attache a un autre processus);un changement de thread serait donc moins lourd qu'un changement de processus.

1) ça, ça n'implique jamais qu'une gestion lorsque le processus se termine. Après, il suffit d'avoir des verrous pour que les 2 threads ne lisent pas le fichier en même temps (et de toute façon tu n'y couperas pas même si tu fais la distinction thread/processus). Je ne vois pas en quoi le fait de changer de processus est plus coûteux que de changer de thread?

que les deux threads lisent un fichier en meme temps, ce n' est pas embetant, c'est lors de la lecture;
selon mon opinion,(peut-etre que je me trompe) changer de thread ne requiert que le changement des registres et d'un ou deux pointeurs,tandis que le changement de processus requiert un changement de registres ,de descripteurs et peut-etre d'autre chose auxquels je n'ai pas pense

autre chose , le systeme que j'ai l'intenteion de faire devrait etre tres oriente programmation avec un compilateur C incorporee , et une routine de compression/decompression pour pouvoir recompiler le noyau et les serveurs sans ordinateur;pour l'instant , ca me laisse 3 possibilites:
-soit je le fais moi-meme (tres long)
-soit je reprends cc en essayant de l'ameliorer (un peu moins long)
-soit j' utilise GTC (aleatoire puisque je ne l'ai pas) que je n'aurais pas a modifier (donc plus rapide

apres ca je ne pense pas qu'une premiere version puisse sortir avant l'annee prochaine

que les deux threads lisent un fichier en meme temps, ce n' est pas embetant, c'est lors de la lecture;

Hum oui tu as raison, je pensais qu'il fallait qu'elle n'accèdent pas au pointeur de fichier en même temps, mais typiquement ce qui va se passer c'est qu'il y aura deux pointeurs indépendants donc le problème ne se pose pas. Ca reste valable si les deux threads peuvent potentiellement écrire dedans (par exemple, si c'est un log).

selon mon opinion,(peut-etre que je me trompe) changer de thread ne requiert que le changement des registres et d'un ou deux pointeurs,tandis que le changement de processus requiert un changement de registres ,de descripteurs et peut-etre d'autre chose auxquels je n'ai pas pense

Des descripteurs? Tu peux détailler _exactement_ ce qu'il faudra faire, selon toi, pour changer de processus en enlevant ce qu'il faut faire pour changer de thread?

autre chose , le systeme que j'ai l'intenteion de faire devrait etre tres oriente programmation avec un compilateur C incorporee , et une routine de compression/decompression pour pouvoir recompiler le noyau et les serveurs sans ordinateur;

Arf, OK. Mais fais extrêmement attention à la RAM, dans ce cas. Un compilateur C, ça a besoin d'une RAM folle pour faire un minimum d'optimisation, donc il faut que tu puisses avoir un mode "économie de RAM" où il n'y a qu'un seul processus et où toutes les tailles sont réduites à leur strict minimum (notamment pour les piles).

-soit je reprends cc en essayant de l'ameliorer (un peu moins long)

Oui, c'est possible. Mais il y a tout un tas de bug pervers que j'ai vu dans C68k qui sont probablement aussi présents dans CC.

-soit j' utilise GTC (aleatoire puisque je ne l'ai pas) que je n'aurais pas a modifier (donc plus rapide)

Oui, c'est possible aussi. Mais j'ai pas recompilé la version on-calc depuis très longtemps (6 mois). Va falloir enlever toute la poussière qui traîne autour


Et enfin, tu vas faire ton OS sous Pedrom? Je pense que pour des questions de RAM, tu as vraiment intérêt soit à en faire une FlashApp, soit une app Pedrom (idéalement les deux).

* As-tu regardé ma source de Task Switcher? http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=106.topic. J'utilise l'AI6 (task switching manuel), mais on peut tout autant utiliser l'AI 1 ou 5 (timers) si on s'arrange pour la gestion du clavier et de la souris.
* On peut généralement se passer de locks et de sémaphores. Au pire, on bloque le scheduler avec un OSSetSR.

Et puis, pour les fichiers, on a déjà notre système de lock: bset met et teste un bit en même temps, donc il suffit de faire un bset sur le bit in-use.

Au pire, on bloque le scheduler avec un OSSetSR.

Miam

Et puis, pour les fichiers, on a déjà notre système de lock: bset met et teste un bit en même temps, donc il suffit de faire un bset sur le bit in-use.

Oui, je parlais de TAS mais c'est vrai aussi pour bset. Enfin toujours est-il qu'il faut y penser et qu'on ne peut pas supposer que le compilateur C optimisera de cette façon-là (déjà parce qu'il n'est pas parfait, et ensuite parce qu'il peut y avoir des optimisations meilleures qui ne sont pas thread-safe), il faut passer par des routines ASM.

Évidemment qu'on ne fait pas un sémaphore en C!
On peut par exemple utiliser une fonction ObtainFileLock(SYM_ENTRY *f asm("a0")) codée en assembleur.