Opale: noyau multithreadé pour TI-68k - Page 2

Et il y a toujours la possibilité de dual-licenser LGPL + licence plus fermée. Voir Qt, MySQL.

Enfin là ça n'a pas trop d'interêt. Qt et MySQL sont sous double licence GPL/licence commerciale (et bien sûr la licence commerciale est payante). Le choix d'une double licence a uniquement pour but de devenir une source de revenu dans le cas de programmes clients propriétaires.

En effet, les exemples sont mauvais.
#30 donne une indication quant à la future licence de certains programmes de TICT...

Précision: ... si les contributeurs sont d'accord. C'est pour ExtGraph que ça pourrait poser un problème, si un ne veut pas accepter le passage en licence double.

Une double-licence de quelle type ?

Licence actuelle (pour ne rien casser) + LGPL (compatible GPL, mais moins contraignante).

Mais comme l'ancienne licence est plus contraignante que la LGPL, couvrir uniquement les nouvelles versions avec la LGPL suffirait (les programmes utilisant les version précédentes suivent l'ancienne licence, ça ne pose pas non plus de problème).

Oue sauf que non. La LGPL impose de pouvoir relirer avec n'importe quelle version de Extgraph (meme personnelle).

Tu réponds à #36 ou #37 ?

#37

Oui enfin toussa je suis pas sur que ça ai bcp de rapport avec Opale...

Indirectement, ça parle un peu de licenses, et le débat m'intéresse un peu (même si parler du noyau m'intéresserait plus, mais bon y'a pas tout encore )

Un seul programme qui aurait plusieurs threads.
Déjà, y'a pas de MMU sur TI à proprement parler.
Ensuite, je ne vois pas du tout l'intérêt de "multitâcher" des programmes existants, puisque la plupart des programmes ne sont de toutes façons pas utilisables en même temps, et ensuite que les ressources sont bien faibles. Pour moi les "switchers" existant ne sont que de peu d'intérêt, sinon de performance technique.

PpHd :
Oue sauf que non. La LGPL impose de pouvoir relirer avec n'importe quelle version de Extgraph (meme personnelle).

Je ne vois pas trop, où est le problème ?

Ximoon : à ton avis, ce serait possible d'adapter Opale pour le faire marcher avec des hooks, en même tant que l'AMS ? (une idée comme ça sans trop réfléchir, qui permettrait d'éviter un lourd travail d'adaptation des threads Linux pour l'USB).

ExtendeD> a priori tu peux l'utiliser en parallèle d'AMS tant que tu ne fais pas n'importe quoi avec les ports et les variables en général... maintenant je ne sais pas ce que tu appelles "le faire marcher avec des hooks"

Martial> N'importe quel programme basé sur des I/O par exemple, pour de l'évênementiel, ou autre...
Pour les libs graphique j'ai au programme une tentative d'utilisation avec Genlib mais je ne sais pas ce que ça va donenr avant de l'utiliser
Enfin bon, avec d'énormes pincettes, a priori les nvg ne devraient pas gêner le noyau et inversement. A tester (j'ai vaguement tester, mais pas en profondeur).

Ximoon :
maintenant je ne sais pas ce que tu appelles "le faire marcher avec des hooks"

Les threads sont des hooks (résidents), qui tournent en // de l'AMS, et le scheduler ne conflicte pas avec les auto-int de l'AMS (ou n'importe quoi de l'AMS).

a priori tu peux l'utiliser en parallèle d'AMS tant que tu ne fais pas n'importe quoi avec les ports et les variables en général...

Tu veux dire les variables de l'AMS ?

A mon avis Martial vous ne parlez pas de la meme chose...

ExtendeD
:

Ximoon :
maintenant je ne sais pas ce que tu appelles "le faire marcher avec des hooks"

Les threads sont des hooks (résidents), qui tournent en // de l'AMS, et le scheduler ne conflicte pas avec les auto-int de l'AMS (ou n'importe quoi de l'AMS).

a priori tu peux l'utiliser en parallèle d'AMS tant que tu ne fais pas n'importe quoi avec les ports et les variables en général...

Tu veux dire les variables de l'AMS ?

Bon alors dans l'état actuel du noyau, il se greffe par dessus l'int 5 pour l'interruption du noyau elle-même (tick système).
Les traps 6,7 et 8 sont détournés de respectivement rien vers SchedulerISR, EnterCriticalSectionISR et ExitCriticalSectionISR.
A part ça, il n'y a aucune interraction avec AMS.
La seule chose qui pourrait éventuellement poser problèmes serait des changements intempestifs du masque d'interruption, et encore.
Faudra vraiment que je m'y remette pour documenter le tout.

Martial Demolins :
tiens ExtendeD, tu pourrais me dire en deux mots ce que tu entends par scheduler (notion confuse chez moi )

Dans un noyau multi-tâche (au sens large), le scheduleur, ou ordonnanceur de part chez nous, est la partie du noyau qui est chargée de désigner quelle est la tâche qui doit s'exécuter. Il y a de nombreux algorithmes différents pour faire ça, selon l'effet que l'on veut: avoir un système réactif à des évênements donnés, donner autant de temps processeur à toutes les tâches, privilégier certaines tâches, etc.

Martial Demolins :
http://www.linux-france.org/prj/jargonf/S/scheduler.html
http://fr.wikipedia.org/wiki/Ordonnancement_dans_les_syst%C3%A8mes_d'exploitation
[edit : croisé]

Bon alors dans l'état actuel du noyau, il se greffe par dessus l'int 5 pour l'interruption du noyau elle-même (tick système).

Ok. Pas de changement de la fréquence de l'AI5 ?

Les traps 6,7 et 8 sont détournés de respectivement rien vers SchedulerISR, EnterCriticalSectionISR et ExitCriticalSectionISR.

Ah oui. Mais pourquoi passer par des traps ? Je me souviens plus, AMS utilise ces traps, lui ?

La seule chose qui pourrait éventuellement poser problèmes serait des changements intempestifs du masque d'interruption, et encore.

Ok, ça doit s'arranger ça.
Je vais creuser ça, je crois que ça va faciliter pas mal de choses.

ExtendeD :
Ok. Pas de changement de la fréquence de l'AI5 ?

Non, je reste à la fréquence de base (environ 18Hz pour autant que je sache) sans rien toucher.

ExtendeD :
Ah oui. Mais pourquoi passer par des traps ? Je me souviens plus, AMS utilise ces traps, lui ?

Ceux-là ne sont pas utilisés, sauf si ça a changé très récemment. Les traps, c'est chouette pour passer en mode superviseur.

ExtendeD :
Ok, ça doit s'arranger ça. Je vais creuser ça, je crois que ça va faciliter pas mal de choses.

Tu veux les sources complètes pour t'amuser ?
Bon après je n'offre aucune garantie de la fonctionnabilité de l'ensemble pas plus qu'au caractère non bogué du tout.

Ximoon :
Ceux-là ne sont pas utilisés, sauf si ça a changé très récemment. Les traps, c'est chouette pour passer en mode superviseur.

Tiens, passer en superviseur ? Avec AMS derrière, ça sera mieux d'utiliser uniquement le trap #12 pour ça, plus sûr contre les MAJ d'AMS.

Tu veux les sources complètes pour t'amuser ?

Oui, je veux bien

Bon après je n'offre aucune garantie de la fonctionnabilité de l'ensemble pas plus qu'au caractère non bogué du tout.

Pas de problème, ça sera débuggé en temps voulu s'il le faut.

http://mapage.noos.fr/cmolon/opale/Opale-sources-beta2-01-08-2005.zip

Sources actuelles, pour les intéressés. Niveau license, réutilisation et modifications autorisées au cas par cas en attendant mieux.