Le taint des drivers propriétaire est P, mais je verrais plutôt un D qu'un P. Suis-je le seul ?
tant que c'est pas printkk...
oui mais dans le libromonde de kewin ça veut dire qu'un putain de founisseur de fucking code propriétaire a mis sa bite dans la vierge gpl-effarouchée de Saint Gnu.
[HS ON]Au fait, navré d'être stupide, mais, heu... kernel (enfin ça je sais) mais nostub, sékwah ?[HS OFF]
Kochise
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/
ce sont les programmes qui marchent en standalone, sans aucun support logiciel derrière. Le premier octet du fichier est de l'assembleur et est exécuté directement, pas de stub. Ils embarquent tous leur détection hw, détection d'os et de plein d'autres trucs, et pètent à chaque maj de l'un ou l'autre. Ils ne supportent pas les librairies dynamiques et doivent tout réinventer pour faire quoi que ce soit d'intéressant.
Bah, alors déjà c'est une discussion qui n'est intéressante que sur les calculatrices (ou à la limite d'autre matériel embarqué), donc totalement HS ici…
Et ensuite la description de Folco n'est pas très objective: 1. Il y a un support logiciel: celui du système d'exploitation. Notamment, une grande table de fonctions (les ROM_CALLs) est exportée par celui-ci, donc on ne doit pas tout réinventer. 2. Ils ne cassent pas forcément à chaque mise à jour, et de toute façon TI n'a pas l'air d'encore vouloir sérieusement mettre à jour la série 68k. 3. Le grand avantage est qu'ils fonctionnent sans devoir installer quoi que ce soit. 4. L'absence de libraries dynamiques est aussi un atout du point de vue de l'utilisateur, sur une plateforme où il n'y a pas de logiciels comme apt ou yum qui s'occupent des dépendances automatiquement (c'est ça qui rend les libraries dynamiques aussi efficaces sous GNU/Linux).
Hors comme 99% des libs sont dans stdlib, le kernel l'emporte haut la main \o/
disons qu'en nostub on utilise uniquement les fonctions du TOS, comme si t'avais un programme au format "bin" dont l'exécution est directe. ça utilise que des libs statiques type libc, dont les fonctions s'appuient uniquement sur l'OS.
en kernel, on a un ensemble de routines utilitaires qui gèrent, entre autres, des libs. en fait le kernel intercepte les demandes d'exécution des programmes ASM, lit les premiers octets du fichier (header ou stub), résout et charge les libs nécessaires, fait sauter des protections, fait des relogements, puis exécute le point d'entrée. C'est un peu ce que fait un PC normal avec un loader, des .exe et des .dll
Godzil Le 28/09/2010 à 16:35Edité par Godzil le 28/09/2010 à 16:37 (Ce qui m'effare, c'est que je connais mieux le kernel, que Kevinochou adore, que Kevinounet lui meme...)
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Le _nostub est aussi relogé.
• Godzil va aller installer une MMU comme ça on pourra mettre le relogement a la poubelle, PIC is bad
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Le fait de faire du code PIC, donc avec uniquement des adressages pc-relatifs n'est utilisé par moi que dans un but : produire un binaire à la section de code parfaitement invariante, de manière à pouvoir être exécuté en ROM sans recopie en RAM (sous PedroM).
