• [^] # Re: solution module noyau

    Posté par (site web personnel) . En réponse à la dépêche Temps réel avec le noyau Linux. Évalué à 2.

    Un premier problème est l'impossiblité d'utiliser la glibc, ou toute autre librairie (je sais même pas si il y a des fonctions permettant aux modules d'ouvrir un fichier). Toujours est-il que le fait de tout programmer au niveau du noyeau sappe l'interêt de la technique puisque les applications ne ressemblent plus à des applications GNU/Linux standards. À ce moment là, autant programer sur un vrai noyeau temps réel (y'en a des libres).
    D'ailleurs ça serait peut être pas si efficace paske la latence dépendrais de ce qui se passe ailleurs dans le noyeau. Et, sans pouvoir en être sur, je doute de la qualité de l'ordonanceur qui gère les diffèrents modules et du fait qu'il permette (par exemple) d'interrompre un module à n'importe quel moment pour lui substituer un module de priorité supèrieure (je crois pas qu'il gère la notion de priorité). Donc le système serais bloqué si le module est trop important.
    Après on peut faire on module qui se charge juste de ce qui est fortement contraint et comunique avec l'espace utilissateur pour le reste, mais ça reviendrais à réinventer la roue puisque des kits (dont RTAI) existent pour ça.

    Tout ces problèmes sont contournés par la solution retenue par certains projets (comme RTLinux si je confonds pas), à savoir ajouter un vrai ordonanceur temps réel qui se place "au dessus" du noyeau (pour cet ordonanceur, GNU/Linux est ses applications sont un process, de même que chaque application temps réel). Elle semble donc bien avoir un interêt.
    Et RTAI aussi, qui intercepte certaines interruptions pour donner la main à ses applications temps réel quand elles ont lieu (dans l'optique de répondre rapidement à un périphèrique) (si j'ai bien compris).