Journal Sortie de haskus-system 0.7

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
55
30
juin
2017

Bonjour,

Je n’ai encore jamais parlé ici du logiciel que je développe. Comme je viens d’annoncer la sortie de la version 0.7, c’est l’occasion. Ça parle de Linux et de Haskell.

Qu’est‐ce que c’est ?

L’idée de base consiste à prendre le noyau Linux seul (sans libc ni rien) et à refaire les couches d’abstraction au‐dessus en Haskell. Ça permet de faire de la programmation système tout en bénéficiant du système de types, de la mémoire transactionnelle, des green threads, etc.

Comme ça n’est pas forcément clair, on peut voir ça comme une sorte d’Android où Java aurait été remplacé par Haskell ou comme haskus-system/Linux (par analogie avec GNU/Linux). Je suis encore loin d’avoir les fonctionnalités d’Android et de GNU, c’est juste pour l’image.

Pour l’instant, je me suis principalement attaqué aux sous‐systèmes d’entrée et à l’affichage (DRM) pour interagir avec l’utilisateur. J’ai fait le lien avec Diagrams, ça nous fait une sorte de Cairo en Haskell.

haskus-system est une bibliothèque : chacun peut l’utiliser pour faire le « système » qu’il veut. Un système se présente sous la forme d’un programme d’init (dans un ramdisk, pour que ce soit simple à utiliser).

Nouveautés de la version 0.7

Avant cette version, il était relativement compliqué de tester un système. Il fallait manuellement compiler Linux, créer le ramdisk, configurer et installer Syslinux, lancer QEMU avec les bonnes options, etc.

J’ai automatisé tout ça : maintenant, il suffit de déclarer la version de Linux à utiliser et quelques autres options dans un fichier system.yaml et l’outil haskus-system-build télécharge, configure et construit tout automatiquement.

Pour tester un exemple avec QEMU il suffit de faire :

$ git clone https://github.com/haskus/haskus-system-examples/
$ cd haskus-system-examples
$ haskus-system-build test --init Demo

Voir le manuel utilisateur pour savoir comment installer l’outil et pour voir la liste des logiciels à installer pour qu’il fonctionne (stack, git, lzip, gcc, cpio, etc.).

  • # Haskus

    Posté par  . Évalué à 10.

    Just a hobby, won't be big and professional like gnu ?

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Haskus

      Posté par  . Évalué à 6.

      Super boulot en tous cas

      Kudos !

    • [^] # Re: Haskus

      Posté par  (site web personnel) . Évalué à 3.

      Exactement ;-)

      PS : il manque "fd" dans l'url de ta signature si je ne m'abuse

      • [^] # Re: Haskus

        Posté par  . Évalué à 2.

        ?

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Haskus

          Posté par  . Évalué à 3.

          L’adresse dans ta signature est invalide. Je t’avais déjà fait la réflexion il me semble :)

  • # Bravo

    Posté par  . Évalué à 9.

    Bravo ! C'est super comme projet. Tu travail dessus depuis combien de temps ?

    Tu as des retours à faire ? Quels sont les points qui t'embêtent le plus et ceux qui coulent tout seul ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Bravo

      Posté par  (site web personnel) . Évalué à 8.

      À la base en 2013 le projet s'appelait ViperVM et le but était de faire un support exécutif pour les architectures hétérogènes (GPGPU, etc.) pour ma thèse. cf https://dl.acm.org/citation.cfm?doid=2502323.2502329
      En 2014 j'ai réorienté le projet dans le sens actuel, donc on peut dire que ça fait 3 ans.

      Pour les retours, globalement ça marche plutôt bien. Côté Linux, il faut parfois réussir à trouver de la documentation. J'ai noté quelques détails qui pourraient être améliorés :
      https://github.com/hsyl20/haskus-system/issues
      http://hsyl20.fr/home/posts/2016-04-05-predefined-shared-error-sets-considered-harmful.html
      Je regrette aussi que l'API "atomic" de DRM ne soit pas encore supportée par tous les drivers.

      Côté Haskell, je n'ai pas eu trop de problèmes techniques (seulement un patch pour le runtime system de GHC afin de pouvoir exécuter un binaire statique dans un initramfs sans avoir besoin des fichiers de iconv et un autre pour que le runtime system utilise timerfd plutôt que des signaux).

      Il reste des problématiques de type "recherche" par contre. Par exemple, je ne veux pas utiliser d'exception pour propager et traiter les erreurs renvoyées par les appels systèmes. Je veux que le compilo vérifie que tous les cas sont traités. Du coup j'ai conçu un système qui ressemble aux Checked exceptions de Java mais en mieux (avec du polymorphisme, etc.) mais on atteint un peu les limites du type-checker en terme de performances (à la compilation, pas le code généré).

  • # sans libc?

    Posté par  . Évalué à 4.

    Si je comprend bien, c'est une alternative a la libc pour haskell? Pas les utilitaires sh/ls/grep&co?

    • [^] # Re: sans libc?

      Posté par  (site web personnel) . Évalué à 7.

      Pas exactement. Je ne me propose pas de refaire un UNIX-like (et tous les outils qui vont avec). Il s'agit plutôt de proposer une API de plus haut niveau (un peu comme ce que fournit Android à ses applications, pour ce que j'en sais), donc un peu plus complet que la libc puisqu'il y aura aussi l'API pour gérer l'affichage, le son, le réseau, etc.

      • [^] # Re: sans libc?

        Posté par  . Évalué à 5.

        D'accord, donc c'est une bibliothèque qui permets de coder des outils (en haskell) sans avoir de dépendance au code C, y compris pour les action bas niveau?

      • [^] # Re: sans libc?

        Posté par  . Évalué à 3.

        Dans le cas d'Android, il s'agit de java (enfin de dalvik) donc quand sa touche au bas niveau c'est via du C (par JNI). Dans ton cas si j'ai bien compris il y a ses propres syscall, comme on peut trouver en Go.

  • # haskell paresseux => green thread ?

    Posté par  . Évalué à 2.

    J'ai retenu de haskell que c'est de la programmation fonctionnelle et qu'il est paresseux : ne sont exécutées que les fonctions dont les entrées ont changé… j'imagine qu'il y a un lien avec le terme « green thread ». J'ai bien compris ? ce serait super d'avoir un peu plus de détail là-dessus ?

    (Si j'ai juste, j'ai l'impression le projet constituerait une excellente base pour des applications embarquées avec consommation réduite)

    • [^] # Re: haskell paresseux => green thread ?

      Posté par  (site web personnel) . Évalué à 2.

      Hmm ça n'est pas exactement ça l'évaluation paresseuse : ne sont exécutées les fonctions que si leur résultat est requis. Un peu comme en C si tu écris :

      int x = 1 || toutEffacer();

      la fonction toutEffacer ne sera pas appelée puisqu'on n'a pas besoin de son résultat. Avec l'évaluation paresseuse on généralise cette approche.

      Les green threads (ou threads en espace utilisateur, ou threads M:N, etc.) c'est autre chose : c'est le runtime system de GHC qui effectue l'ordonnancement de threads en espace utilisateur beaucoup plus légers que les threads POSIX par exemple. Ça permet d'en créer beaucoup plus à moindre coût.

      J'aimerais aussi à terme tester sur de l'embarqué (ARM, etc.) mais pour l'instant je ne supporte que x86-64.

      • [^] # Re: haskell paresseux => green thread ?

        Posté par  . Évalué à 3.

        J'aimerais aussi à terme tester sur de l'embarqué (ARM, etc.) mais pour l'instant je ne supporte que x86-64.

        Pourquoi? Haskell est si dépendant du processur?

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.