Work in Progress: Pyrix "Zero" - Page 1

Vala, le noyau Pyrix 0.0.1 ("Zero") est en pleine préparation, à des stades
d'avancement divers... le scheduler est déjà très développé, le système de
fichiers un peu, le bootloader un tout petit peu, les E/S et la gestion de la mémoire pas
du tout...

Pyrix est un projet de système Posix-like très léger, programmé from scratch
et inspiré de diverses choses...
A terme il voudrait être un exonoyau (=micronoyau 2de génération pour les dingues de L4)
temps réel (n'allez pas me dire qu'un microkernel communiquant par ports peut faire un bon
RTOS, les ports ça rame du ***), bien que pour l'instant il n'a pas
encore grand'chose du caractère que ça devra avoir. (Mais d'autres parties sont déjà clairment
dignes de ce nom)

J'ai besoin de différentes choses, des questions au niveau de ce qsue vous préfèreriez pour
Pyrix, et puis de développeurs.

Au niveau de la licence, Pyrix sera booté comme on veut (le premier bootloader devrait
être une version modifiée du code de boot de PedRom, appelé Lighter, qui serait donc
sous licence GNU). Le code de l'exokernel et des processus op (= les serveurs)
sera closed-source mais ce seront des fichiers objets séparés avec assez de doc pour qu'on
puisse faire un autre OS pas trop difficilement (de plus je devrais libérer les sources de
l'exonoyau et des anciennes versions après un petit bout de temps)

Bon, là où j'ai des choses à vous dire, c'est que:

- Y'a besoin d'une libc. Elle sera basée sur la librairie TIGCC et donc sous sa licence,
et j'encouragerai le maximum de monde à la développer.

- La méthode de compilation reste à voir. TIGCC sera toujours là, mais le linker devrait
changer (un autre linker basé sur ld-tigcc, car je ne pense pas que Kevin accepte
l'export A.OUT OMAGIC ou ELF dans un linker pour AMS...), et de plus la lib serait
la libc de Pyrix... donc peut-être une distrib spéciale de TIGCC.

Mais ça c'est plutôt lointain... Pour l'instant j'aurais des choses à vous demander:

- Le système de fichiers: VAT (qui permettrait un émulateur AMS basé sur PedRom pas
trop difficilement) ou un système vraiment Unix-like, avec des superblocs et des inodes ?

(le système de fichiers marche avec des vnodes et des superblocs, mais les inodes
ne sont pas obligés d'exister réellement, --> pareil que sous Linux)

Encore une fois, si tu dérives ton bootloader de PedroM, tu n'as pas le droit de linker tes fichiers objet non-GPL dans le même exécutable (qui dans ce cas est un fichier TIB). À moins que PpHd ne te le permette explicitement.

Est-ce que l'os serat compatible avec AMS ??

Pourquoi "ton" code sera-t-il closed source ?

*Encore une fois, si tu dérives ton bootloader de PedroM, tu n'as pas le droit de linker tes fichiers objet non-GPL dans le même exécutable (qui dans ce cas est un fichier TIB). À moins que PpHd ne te le permette explicitement.*

Bon, on se débrouillera sans PedRom alors
(mais j'ai fait une structure pour que ça puisse se faire au choix. Moi par exemple avec
un hack j'ai pas besoin de code PedRom )

*Pourquoi "ton" code sera-t-il closed source ?*

Oui c'est bien mon code car PedRom n'est utilisé (que pour l'instant d'ailleurs)
seulement pour le bootcode, et tout le reste, ce qui fait BEAUCOUP,
(kernel+sheduler+mm+fs+i/o kit+shell+libc+....) est de moi...
(Et j'ai pas envie de le laisser de l'avance là-dessus vu tout ce que j'en chie....
je publierai le code des anciennes versions )

et le /2 ?

Justement, ça dépend.
J'avais eu deux idées: faire un ému AMS reprenant l'intégralité de PedRom "hacké"
pour fonctionner par dessus Pyrix. (Mais il faut que Pyrix utilise la VAT alors, sinon
ça sera la merde...)

Ou bien faire une notion de partitions (sur base2 en ROM) et avoir une partition
VAT avec un PedRom un peu retouché et une partition FrostBlade pour Pyrix.

(Mais cela demanderait des outils plus perfectionnés qu'un simple ld-tigcc,
genre un exécutable dédié à la production de TIBs)

C pkoi que tu développe Pyrix (apprentissage, défi, gloire, pasque pedrom et AMS sont tous pourris, ...) ??

Surtout pour le défi, et parceque ça n'a pas été fait avant. (Et que j'aime les système
Unix-like et qu'en avoir un à emporter partout ça me plairait sacrément)

Billy Charvet
: Surtout pour le défi, et parceque ça n'a pas été fait avant.

Mouais... RTEMS a déjà été porté sur TI-92 Plus il y a X années (je ne me souviens plus exactement), il tournait sous VTI (j'avais pas les moyens de mettre ça sur ma calc à l'époque). J'en ai déjà parlé sur yN une fois, mais comme j'estime que ça sert vraiment à rien, je me suis abstenu de me la péter avec.

Je n'ai plus de traces de cette époque, mais pour ceux qui veulent tenter l'expérience c'est vraiment pas compliqué. Il suffit de rajouter une "board" TI-68k dans les sources, si la version actuelle est toujours architecturée comme avant. Après pour le userland, busybox + ucLibc (ou newlib plutôt, je ne sais plus) passaient bien. Je n'ai pas fait beaucoup de tests, mais ça boutait sous VTI, et le noyau complet prenait 70k, compilé avec le gcc de l'époque.

bah fait la deuxième idée.

Y'a besoin d'une libc. Elle sera basée sur la librairie TIGCC et donc sous sa licence, et j'encouragerai le maximum de monde à la développer.

C'est à peut près le seul truc qui me parait un peu interessant dans ton projet si jamais c'est réutilisable sur AMS, PedroM.

Le système de fichiers: VAT (qui permettrait un émulateur AMS basé sur PedRom pas trop difficilement) ou un système vraiment Unix-like, avec des superblocs et des inodes ?

Moi je voudrais vraiment UNIX-like. Si tu cherche a concurencer PedroM avec un modèle closed-source c'est vraiment bête.

*C'est à peut près le seul truc qui me parait un peu interessant dans ton projet si jamais c'est réutilisable sur AMS, PedroM.*

Ben, en utilisant TIGCCLIB, on a déjà toutes les primitives printf, scanf etc, ainsi que les
headers avec définitions courantes comme assert.h avec la macro assert,
en bref même si un peu plus de détection Posix pourrait se faire attendre ben on peut
largement considérer que TIGCCLIB est la libc de l'AMS.

*Moi je voudrais vraiment UNIX-like. Si tu cherche a concurencer PedroM avec un modèle closed-source c'est vraiment bête. *

Ah non je cherche vraiment pas à concurrencer PedRom.
Bon à y réfléchir, pour le code de PedRom qui risque de servir (pendant un moment du moins,
j'aimerais l'éliminer aussi vite que possible) ben je publierai peut-être en GNU.

Ben, en utilisant TIGCCLIB, on a déjà toutes les primitives printf, scanf etc, ainsi que les
headers avec définitions courantes comme assert.h avec la macro assert,
en bref même si un peu plus de détection Posix pourrait se faire attendre ben on peut largement considérer que TIGCCLIB est la libc de l'AMS.

pour moi TIGCCLib est loin d'être une libc complète. Il maque pas mal de truc. vu qu'elle a été faite pour AMS c'est plustôt normal mais sur PedroM ca manque.

bon parlons concret, a quand les sources et une beta ?? (approximation)

Le 31 février 2042.

Ben, ces vacances si je m'y mets bien et que je suis pas trop occuppé à autre choses...
Mais faut pas rêver, ça sera pas méga-complet dès le départ...

nitro
:

Billy Charvet
: Surtout pour le défi, et parceque ça n'a pas été fait avant.

Mouais... RTEMS a déjà été porté sur TI-92 Plus il y a X années (je ne me souviens plus exactement), il tournait sous VTI (j'avais pas les moyens de mettre ça sur ma calc à l'époque). J'en ai déjà parlé sur yN une fois, mais comme j'estime que ça sert vraiment à rien, je me suis abstenu de me la péter avec.
Je n'ai plus de traces de cette époque, mais pour ceux qui veulent tenter l'expérience c'est vraiment pas compliqué. Il suffit de rajouter une "board" TI-68k dans les sources, si la version actuelle est toujours architecturée comme avant. Après pour le userland, busybox + ucLibc (ou newlib plutôt, je ne sais plus) passaient bien. Je n'ai pas fait beaucoup de tests, mais ça boutait sous VTI, et le noyau complet prenait 70k, compilé avec le gcc de l'époque.

c'est une idée qui a de l'idée (hum je sors)

RTEMS a l'air d'etre une bonne base

Le noyau de Pyrix DOIT prendre 64 Ko au grand maximum, mais ce sera faisable je pense:
Il n'y a que 37 appels systèmes que je veux implémenter, les autres étant inutiles et truqués
(getuid, setuid etc... remplacés par des macros car il n'y a ni plusieurs comptes utilisateurs, ni groupes ni sessions)

Pour la lib, quelquechose comme ucLibc ou même plus compact
(au départ je voulais adapter ucLinux, mais c'est trop lourd, faut bien 512 Ko de RAM et ça on a pas ,
de plus pour le simplifier ben c'est les sources du noyau 2.4, donc dans les 4 millions de lignes de code )

*pour moi TIGCCLib est loin d'être une libc complète. Il maque pas mal de truc. vu qu'elle a été faite pour AMS c'est plustôt normal mais sur PedroM ca manque.*

J'ai cherché les constantes et fonctions C/POSIX les plus utilisées, et je les ai toutes trouvées...
TIGCCLIB est vraiment très bien. La libc de Pyrix s'appuiera *très fortement* dessus.
(En d'autres termes ce sera TIGCCLIB modifiée pour marcher avec Pyrix)


Divers choix technologiques:

- Appels systèmes: passage des arguments par registre (Vive TIGCC )
- Format exécutable: Soit a.out (OMAGIC like) soit ELF si je me renseigne un peu plus
(Mais au niveau de la TI ça fait vraiment aucune différence....)


VOulez-vous que l'exécution se fasse en ROM ou en RAM ?
En RAM: plus rapide, devrait être ainsi...
En ROM: bien plus d'espace...

En RAM quand y a de la RAM, en ROM quand y a pas de RAM^^

Bah faut voir.... bon de toute façon pour l'instant le système de fichiers ne permet
des fichiers de plus de 64 Ko (mais ça peut très vite se régler... )
Donc je pense que je vais faire l'exécution en RAM...
Mais quand c'est impossible (donc exec en ROM), que faire avec la RAM...? Y mettre autre chose, du genre .data et .bss en RAM ?

tu voudrais mettre les bss en ROM

Et les .data aussi

Sans conter qu'on est sur une plateforme embarqué, pas sur un pc, donc l'execution en rom est tout a fait faisable contrairement a l'execution depuis un disque dur ou autre périph du genre

D'ailleurs je comprends comment tu vas faire pour reprendre "tigcclib" sans reprendre PedroM

Ben pour l'instant y'a deux projets (qui dans l'idéal devraient se rejoindre )

L'un d'entre eux est un hack de PedRom en assembleur GNU qui ne reprend que le strict nécessaire
pour booter (Ni VAT ni shell ni rien d'autre), qui ne marche pas.

L'autre est un système permettant de programmer et de lancer des programmes typiques de Pyrix
en a.out sous AMS/PedRom, d'une façon très proche de Prosit (mais ne reprend pas le code, c'est une
implémentation bien trop différente d'un scheduling Unix-like)

Quand les deux pourront fusionner ben... Pyrix sortira.

Quand à tigcclib, soit les fonctions seront rapidement adaptées
(Y'a pas tant de choses à régler pour adapter le Grayscale par exemple)
soit ça fera mal (fopen, là, ça sera entièrement réinventé)

Et avec un jeu de headers supplémentaires et quelques macros, je pense qu'on pourrait faire un
système qui ne demanderait qu'une recompilation pour que tout prog AMS/PedRom marche sous Pyrix.

C'est quoi l'intéret de passer les sources de PedRom en assembleur GNU

se faire chier et se faire chier

en gros

Ximoon> Le compiler avec TIGCC, je suppose.

Bah un gros truc comme ça il ne va quand même pas l'inliner si?
Enfin bon si ça l'amuse, il a sûrement une bonne raison ...

Ximoon :
C'est quoi l'intéret de passer les sources de PedRom en assembleur GNU

L'assembleur GNU est meilleur.