Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Entrevue avec Pavel Fedin
(Entrevue réalisée par Olivier Tigréat - octobre 2011)
|
|
Pour se faire une idée de la santé actuelle du développement d'AROS, on peut consulter la page suivante :
www.ohloh.net/p/aros. Mais
ce lien montre que le développeur russe Pavel "Sonic"
Fedin est à lui seul à l'origine de plus de 3400 contributions SVN en onze ans. Les autres quatre plus grands contributeurs
sont inactifs ou presque depuis cinq ans, sauf Georg Steger qui était encore actif il y a un an. On voit donc
la place considérable qu'est celle de Pavel dans le développement actuel d'AROS.
 Pouvez-vous nous parler de vous :
famille, passe-temps, travail... Quelle est la place d'AROS dans tout cela ?
J'ai 32 ans et je suis marié. J'aime tout ce qui a trait à la technique. Dès mon plus jeune âge j'ai montré l'intérêt le
plus vif pour l'électricité et l'électronique. J'ai un diplôme d'ingénieur en conception électronique. Mais je travaille
en tant que développeur de logiciels, parce que le secteur de la conception matérielle est inexistant en Russie.
Pouvez-vous nous expliquer
vos motivations quand vous avez acheté votre premier Amiga ? Et pourquoi une telle machine en 1999 : n'était-ce pas une
machine plus démodée que "différente" ? Et pourquoi cet intérêt pour les matériels non standard ?
J'ai toujours aimé les matériels non standard. Je ne sais pas pourquoi. Peut-être parce que j'aime la connaissance pour
elle-même, et que j'aime découvrir le fonctionnement des choses. Les PC sous Windows sont inintéressants car ils sont dédiés
à des tâches triviales, comme le traitement de texte de bureau ou la navigation sur Internet.
Et qu'est-ce qui vous a
conduit au Pegasos II et à MorphOS ?
Je souhaitais rester à jour.
Je pense que certains
utilisateurs MorphOS aimeraient savoir si votre projet BootX (permettant le démarrage de Mac OS X sur Pegasos) a abouti ?
Non.
Avez-vous pu continuer le
développement de FireWorks, votre pile FireWire ?
Non. J'ai perdu ma motivation avec l'arrêt du développement de l'architecture PowerPC. Je conserve encore mon Pegasos,
uniquement parce que je serais malheureux de le jeter. Le protocole FireWire est mort lui aussi, et remplacé par l'USB.
Et je n'ai plus de matériel : la caméra DV qui m'avait été donnée pour ce projet est en panne, et je n'ai jamais pu la réparer.
Et AROS : comment a-t-il suscité
votre intérêt ?
Dès que j'ai entendu parler d'AROS, j'ai aimé l'idée. D'abord, il devenait possible de faire tourner un système compatible Amiga
sur les deux machines (à l'époque j'avais un PC avec un Pentium I, construit avec des pièces récupérées, pour faire tourner
MS Office). Ensuite, j'avais un Mac 68k portable, et ça paraissait chouette d'avoir un système Amiga portable.
On vous doit la possibilité
de découvrir les écrans superposés (écrans tirables), comme le permettent les Amiga originaux. Pouvez-vous décrire votre
implémentation ?
Bien sûr. J'ai implémenté une procédure ShowViewPorts() dans le pilote graphique, qui prend une liste chaînée simple des bitmaps :
elle représente les bitmaps à afficher, empilés. Un bitmap comporte également les champs XOffset et YOffset, qui correspondent
à la représentation des champs Offset du ViewPort pour le pilote. C'est au pilote de gérer tout cela.
L'implémentation logicielle est un simple greffon pour la graphics.library, et intercepte trois fonctions :
- 1. LoadView()
- 2. ScrollVPort()
- 3. modifications des Bitmaps
Le greffon assurant la composition des écrans a simplement à ouvrir son propre écran, et y refléter les modifications portées
aux bitmaps composés. Il n'y a pas besoin de faire quoi que ce soit de particulier avec les dispositifs d'entrées d'Intuition,
parce que cette simulation se trouve à un niveau très bas dans le système, et l'Intuition d'AROS gère le déplacement des
écrans de façon native.
Les pilotes qui ne gèrent pas la composition matérielle continuent donc à n'afficher qu'un seul bitmap : celui dans lequel les
autres bitmaps se reflètent.
Prévoyez-vous de continuer
à améliorer la graphics.library et Intuition ?
Oui. Je n'ai pas le temps pour l'instant, mais j'ai des projets. Par exemple, je veux développer un cadre pour la construction
des pilotes d'affichage gérant le déplacement des écrans.
Serait-il possible dans
certains cas (pilotes accélérés matériellement ?) de réduire la taille (comme la fonction BitMapScale() de la graphics.library)
du reflet des écrans dans le bitmap d'avant-plan ? Par exemple pour les rendre tous visibles à la fois, comme Exposé sous
Mac OS X...
Oui, c'est possible. On peut étendre le greffon gérant la composition, avec des sous-systèmes permettant diverses représentations.
Est-ce que les écrans peuvent être
rendus en temps réel ?
Ils sont rendus en temps réel.
Avez-vous réfléchi aux besoins
relatifs à l'implémentation d'une vraie transparence au niveau des fenêtres (ou des layers ?), comme le permettent déjà
MorphOS et AmigaOS 4 ?
J'y ai pensé. Mais je manque de temps, et de connaissances. Je n'ai jamais été un artiste, et le graphisme (y compris dans sa
programmation) m'est totalement étranger. Je comprends à peine GL.
Vous avez fait un travail
considérable au niveau du noyau i386, en particulier pour ce qui est de regrouper le code des différentes versions. Elles
sont maintenant à peu près au niveau du noyau du portage Sam (et en fait elles l'améliorent sur bien des points), qui était
l'état de l'art des travaux de Michal Schulz. Quels seront les bénéfices d'un tel travail ?
Principalement une réduction des différences entre les noyaux, et une augmentation de la réutilisation de code. Cela permet
à chaque changement apporté au noyau d'être testé sur une base aussi large que possible, comme cela a été le cas pour les
nouvelles alertes et pour le suivi de l'utilisation de la pile.
Vous vous êtes porté
volontaire pour la cagnotte ACPI phase 1. Quels bénéfices pouvons-nous en attendre pour AROS sur les plates-formes gérées ?
La phase 1 n'est qu'un petit pas vers tout cela, mais l'ACPI permet :
- 1. L'utilisation de plusieurs coeurs.
- 2. L'utilisation des interruptions matérielles de l'IOAPIC. Certaines machines sont lentes pour l'instant sous AROS (comme
les Mac mini à base d'Intel par exemple) parce que tous les pilotes partagent IRQ0.
- 3. L'utilisation d'horloges de haute précision, permettant une amélioration des opérations utilisant les délais.
Pensez-vous qu'AROS pourrait
bientôt être étendu pour tirer parti des processeurs multicoeurs ? Quelles sont vos idées sur ce sujet ?
Oui, c'est possible. Peut-être d'abord par l'ajout d'une bibliothèque type Exec permettant de faire tourner des tâches dédiées
sur les autres coeurs (approche type PowerUP). C'est beaucoup plus facile à développer qu'un SMP complet (parce que la nouvelle
bibliothèque est sans héritage), mais c'est déjà très utile (par exemple, les encodeurs et décodeurs vidéo pourraient en tirer
parti).
Je sais que vous avez aussi
pensé à la protection mémoire... pouvez-vous en parler ?
Oui, je peux. Les "pools" d'Exec sont déjà prêts : ils ont été réécrits pour utiliser des blocs de taille fixe. Il n'y a plus
de taille seuil, et la taille des flaques (puddles) est toujours un multiple de la taille des pages processeur. Si un gros bloc
est alloué (plus gros que la taille d'une flaque), une flaque élargie est allouée. C'est pourtant toujours une flaque, dont
la fin peut être utilisée pour de petites allocations. Cela permet d'utiliser les "pools" pour séparer les pages mémoire
(obtenues avec l'alloueur du noyau) en blocs de taille variable. Un AllocMem() avec la protection mémoire active est censé
être simplement un AllocPool() système par défaut.
L'alloueur du noyau existe au stade de brouillon et n'est pas encore utilisé.
Je n'ai pas le temps de le tester. Par ailleurs, avec l'implémentation actuelle des "pools", AllocMem() serait lent, parce
que le pool serait mixte. Le même "pool" pourrait contenir des blocs avec des drapeaux différents. Le gestionnaire de "pools"
supporte cela, mais c'est lent. Je réfléchis à la façon de l'améliorer.
Que souhaitez-vous ajouter ?
Je ne sais pas, vraiment. Je manque de temps et d'imagination...
Vous avez souvent amélioré
AROS avec des éléments très inspirés de MorphOS. Quelles sont vos relations avec les développeurs de MorphOS ? Avez-vous eu
accès aux sources de MorphOS ?
Je n'ai pas de relation avec l'équipe de développement de MorphOS. Et je n'ai vu que du code public, ou fuité : si vous vous
en rappelez, ça a été le résultat d'un conflit interne de l'équipe de développement. À cette époque, j'ai publié des améliorations
non officielles pour MorphOS, basées sur ces sources fuitées.
La version d'AROS hébergée
sous Windows est beaucoup plus utilisable qu'aux premiers jours, mais il arrive encore qu'elle "avale" quelques caractères
lors de la frappe au clavier, et elle plante encore de façon aléatoire (très rarement cependant). Pourrez-vous vous pencher
à nouveau dessus ?
Oui, je le ferai. Je ne sais pas quand, mais je souhaite le faire. En fait, j'utilise cette version moi-même, pour installer
les fichiers nouvellement compilés sur les partitions natives de mon portable. Et je sais déjà quoi faire pour la frappe au
clavier. Je rencontre également les blocages, mais je n'en ai pas encore trouvé la cause.
Pourriez-vous expliquer
brièvement comment on peut compiler AROS sous Windows ?
Comme sur toute autre plate-forme. "configure", puis "make". MinGW est nécessaire.
Maintenant qu'AROS tourne sur
les terminaux portables d'architecture ARM, grâce à votre incroyable travail (et à celui de Michal), est-il facile pour les
développeurs de porter des applications sur ces systèmes ? Et y a-t-il une seule sorte d'exécutable, comme c'est le cas sous
i386 où les exécutables fonctionnent sous toutes les moutures ?
Oui, il n'y a qu'une sorte d'exécutable ARM :-) pour processeur ARMv6, avec FPU VPF, sous ABI softbloat. D'autres moutures
sont proposées (par exemple ARMv7 et Neon hardfloat), mais ce n'est pas en production actuellement.
Le portage Android semble être
particulièrement abouti. Qu'en est-il du portage iOS ?
iOS est un système très restrictif. Il est par exemple impossible d'allouer de la mémoire en permettant à la fois la lecture,
l'écriture ou l'exécution de code. Cela ne peut être qu'en lecture-exécution, ou bien en lecture-écriture. Cela implique que
la gestion de la protection mémoire est indispensable pour qu'AROS fonctionne sous iOS.
Je suis revenu vers ce portage récemment, et j'ai amélioré le pilote d'affichage. Je peux tester ce pilote sur un simulateur,
qui utilise l'architecture i386 et n'est pas concerné par les restrictions relatives à la mémoire. Quand j'en aurai fini avec
cela, je terminerai la protection mémoire.
Soutenez le travail d'Obligement
|
|
|
