 |
Vendredi 06 juin 2025 - 01:40 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
On se souvient du salon de Cologne de l'année dernière, durant lequel on avait appris qu'Amiga avait choisi QNX comme base pour les futurs NG. On se souvient également de la démonstration qui avait eu lieu, et qui avait tellement impressionné que lors du retour de veste d'Amiga, de très nombreux amigaïstes avaient manifesté leur opposition. Aujourd'hui QNX revient sur la scène. et ce sur presque toutes les plates-formes, la carte PowerPC G4 de Phase 5 serait concernée. Vous trouverez donc dans les pages suivantes une présentation de ce système d'exploitation discret mais très efficace.
QNX sur le papier
QNX Software Systems Ltd. (QSSL) a été créée en 1980 par Gordon Bell et Dan Dodge pour développer et commercialiser le système d'exploitation temps réel. Dan Dodge est cofondateur et directeur technique. Gordon Bell est quant à lui président et cofondateur. Ils ont étudié sur le même campus (Waterloo, Canada) et fondent QNX Software Systems dès l'obtention de leurs diplômes.
Depuis, ils ont vendu plus d'un million de copies de leurs OS. Le siège social de l'entreprise (départements R&D, ventes et marketing, formation clients) est situé près d'Ottawa au Canada. Des bureaux sont installés aux États-Unis, en France, en Allemagne et au Royaume-Uni. Un réseau de 40 revendeurs est déployé à travers le monde.
Marchés : automatisation industrielle, instrumentation médicale, finance et points de vente, télécommunications, appareils domestiques Internet, informatique de poche, éditeurs de logiciels, fabricants de contrôleurs, instrumentation automobile, électronique grand public.
Quelques partenaires : Cisco Systems, qui, après une longue évaluation de tous les OS disponibles, a choisi QNX comme système d'exploitation de sa prochaine gamme de produits. QNX et Hewlett-Packard se sont alliés pour développer une machine virtuelle Java pour système embarqué. QNX est également compatible avec l'environnement de développement intégré CodeWarrior de MetroWerks - boîte à outils logicielle qui a notamment servi au développement du PalmPilot de 3Com et de la PlayStation de Sony. Enfin, un dernier exemple de partenaire : Philips, qui utilise QNX pour construire des appareils domestiques Internet destinés aux marchés grand public d'Asie.
Concrètement, QNX est utilisé, entre autres, par : AKSYS (périphériques portables d'hémodialyses), Alcatel (périphériques automobiles embarqués), Dupont (imagerie médicale), Ford Motor Company, Loewe (télévision Internet), New York Stock Exchange (service de sécurisation), Visa International (vérification et traitement de transactions), Motorola (fabrications de semi-conducteurs).
Le système d'exploitation
En fait, il en existe deux : le premier est QNX. Le second, Neutrino, est plus récent, également temps réel. mais plus adapté au marché actuel. La dernière version en date, Neutrino 2.0 est adaptée aux processeurs suivants : PowerPC 401, 403 OC, 603e et 604 d'IBM. PowerPC 750, 821, 823, 860, 603e et 604 de Motorola. R4000 (y compris les séries VR41xx) et R5000 MIPS de NEC. Gamme complète des processeurs x86, du 386 au Pentium III. Les bus compatibles sont : ISA. PCI, VME, STD, STD 32 et PC/1O4.
Caractéristiques
Le système est compatible POSIX et très facilement adaptable selon l'objectif voulu : "minimum" pour les systèmes embarqués, "intermédiaire" pour des systèmes multitâches acceptant des milliers d'applications ou "massive et distribuée" pour des applications sur un réseau SMP.
Neutrino permet, de plus, de réduire le nombre de composants. Par exemple, dans le cas de systèmes x86, un BIOS n'est pas nécessaire, puisque Neutrino ne s'appuie pas sur les appels BIOS. De même, les applications peuvent fonctionner directement sans mémoire ROM ou flash. L'interface graphique maison, "Photon", est entièrement configurable.
Les pilotes ("drivers")
Depuis le début, les pilotes pour Neutrino ont été conçus pour être programmés de façon identique quelles que soient les unités centrales et les cartes utilisées. Neutrino fournit des fonctions C qui gèrent les comportements par défaut communs à la plupart des périphériques.
Chaque pilote fonctionne comme un processus standard plutôt que comme un élément du noyau lui-même. Il est ainsi possible de tester les modifications sans avoir à reconstruire le noyau, il suffit de recompiler et de redémarrer le pilote.
Enfin, un réseau sous QNX autorise l'utilisation de toutes les ressources disponibles par toutes les machines : l'adressage mémoire, l'espace graphique, un périphérique où qu'il soit...
En détail
Longueur des noms de fichiers : chaque nom de répertoire ou de fichier composant un chemin est limité à 48 caractères, ce qui est plus que suffisant.
Ajout de périphériques : il suffit de lancer (dynamiquement depuis un "Shell script" de configuration ou depuis le "Shell") le pilote nécessaire au fonctionnement du périphérique. Il existe cependant un certain nombre de programmes d'auto-détection de périphériques (disktrap, nettrap, inputtrap, etc.) dont le rôle est de lancer le ou les pilote(s) nécessaire(s) de façon automatique. Un pilote sous QNX est un processus à part entière qui peut être lancé et arrêté dynamiquement. Ils se développent comme des programmes applicatifs, avec les mêmes outils. Il n'y a pas de morceaux de noyau à "link-éditer", ni même de nouveau noyau à régénérer.
Portage d'applications QNX x86/QNX PowerPC ?
QNX est utilisable sur de nombreux processeurs. Pour porter une application de l'un à l'autre, il suffit de recompiler celle-ci. Pour les pilotes, une couche d'unification du matériel existe et permet de simplifier le portage vers un nouveau processeur (en théorie, une simple recompilation est suffisante).
Portages d'origine Linux
Une application Linux se porte généralement très facilement. Pour un pilote, c'est plus compliqué car ils sont architecturés différemment : simples processus (éventuellement "Resource managers") sous QNX/Neutrino et liés au noyau dans le cas de Linux. Tout dépend de l'architecture du pilote et de la façon dont il a été codé. Généralement, le gros du travail se situe au niveau de l'interface du "Resource manager". Des différences mineures peuvent ensuite apparaître au niveau du "threading" et de "l'interrupt handler".
Dans un système à architecture micronoyau comme QNX, un pilote s'exécute en mode utilisateur (protégé) et non pas en mode noyau. C'est un avantage, puisqu'un problème au niveau d'un pilote ne plantera pas un autre pilote, ni les applications en mémoire et en aucun cas le système d'exploitation lui-même. Au contraire un "watchdog software" peut être installé pour relancer un composant logiciel (pilote ou application) lors d'un plantage si cela est nécessaire.
Cohabitation avec un autre OS sur une même machine
QNX/Neutrino s'installe dans sa propre partition sur le disque dur. Un multidémarrage est fourni en standard : il permet de démarrer sur n'importe lequel des OS installés sur la machine.
Comparaison QNX sur PowerPC G4 et Pentium III
QNX tourne déjà sur PowerPC G4 dans les laboratoires de QSSL. D'après les tests les différences de performances sont énormes, en faveur du PowerPC 7400 (G4) bien sûr. Voici quelques chiffres :
Changement de contexte entre deux fils d'exécution contenus dans le même processus :
PowerPC G4 à 500 MHz : 0,57 µsec.
Pentium III à 450 MHz : 1,2857 µsec.
Changement de contexte entre deux fils d'exécution résidant dans deux processus différents :
PowerPC G4 à 500 MHz : 0,88 µsec.
Pentium III à 450 MHz : 2,004898 µsec.
Appel noyau NOP (entrée dans le noyau, sauvegarde totale du contexte, restauration du contexte puis sortie du noyau) :
PowerPC G4 à 500 MHz : 0,46 µsec.
Pentium III à 450 MHz : 0,777083 µsec.
Gestion de la 3D
QNX est en train d'ajouter la gestion 3D pour Photon. Des négociations sont en cours avec 3Dfx pour permettre l'utilisation de leur API Glide, ce qui donnerait une gestion 3D directe pour les matériels à base de puce Voodoo2 et Voodoo3.
Comme Glide est une API propriétaire, QNX est également en discussion avec la société Criterion qui a développé l'API 3D "Renderware 2" destinée au marché du jeu. Renderware peut être utilisée au-dessus de Glide ou peut être optimisée pour n'importe quel matériel 3D. L'intérêt de Renderware est donc la portabilité quel que soit le matériel utilisé. Pour information, Renderware a été choisie comme API "middleware" par Sony pour la prochaine génération de PlayStation 2.
QNX devrait également gérer MesaGL.
RealAudio
RealAudio et RealVideo 5.0 tournent déjà. QNX travaille actuellement sur le portage des codecs G2 (les premières versions du Realplayer G2 devraient être disponibles au premier trimestre 2000).
Des écrans ?
Il ne s'agit pas exactement du même système que sur AmigaOS, mais le bureau est un espace virtuel qui peut-être divisé en parties. Chacune de ces parties peut-être considérée comme un "écran" avec par exemple l'interface graphique d'un programme.
Réseau QNX
QNX se caractérise par un partage de toutes les ressources de toutes les machines d'un réseau. Il y a une exception : la mémoire n'est pas partagée sur le réseau. Toutes les IPC (communications interprocessus) sont transparentes au réseau sauf celles qui touchent à la mémoire partagée. L'accès aux ressources matérielles distantes ne pose pas de problème si le pilote n'utilise pas de mémoire partagée pour dialoguer avec l'application.
Il faut donc implémenter les pilotes :
- Soit sous la forme de "Resource manager", le dialogue avec l'application s'effectue via un chemin particulier dans l'arborescence (exemple : ldev/serl pour accéder au premier port série).
- Soit sous la forme d'un processus dialoguant avec l'application par l'intermédiaire d'un IPC quelconque en évitant la mémoire partagée (message passing, queue POSIX, etc.).
L'architecture logicielle est une architecture client/serveur au niveau des processus. Au niveau des machines. chaque machine est à la fois cliente et serveur, c'est un réseau "peer to peer". La sérialisation de ces accès dépend du type de ressource car certaines acceptent plusieurs clients et d'autres pas. Si une ressource gère l'accès simultané de plusieurs clients, alors le processus serveur qui la gère va servir les clients en fonction de leurs priorités respectives (par défaut, mais cela peut être changé le cas échéant).
Conclusion
En plus de ses qualités propres comme la garantie temps réel ou son extrême fiabilité, QNX possède d'ores et déjà les capacités logicielles des Amiga MCC, telles que les prévoyaient Amiga Inc. au World Of Amiga.
La notion de "pervasive computing" introduite à cette occasion, existe déjà sur ce "vieil" OS, puisque le partage de toutes les ressources et leur utilisation à distance via Internet, basé sur Java et surtout Jini par Amiga, sont gérés par QNX. Sur le papier, ce système d'exploitation est donc réellement intéressant de par ses performances et sa réputation de fiabilité. Cerise sur le gâteau, QSSL serait en train d'adapter sur Neutrino les caractéristiques si attachantes d'AmigaOS, comme le RAM Disk...
|
