Well, fairly aggressive this title is... But by 'takeoff' I mean... embedded in planes ! For yes, one major project has emerged whose aim is to provide tools to ease DO-178 certification. Plus another project to be announced clearly aims at providing an allegedly restricted but nevertheless hard real time kernel based on Linux.
What real work is not yet done to date ? In my opinion, not much for the description, but this shortly described work means much, a big tedious but careful job to begin.
The remaining areas of concern ?
Well, as most drivers are probably following the good practise guidelines implementing interrupt handlers in 2 parts (either task queue or bottom half), a few probably remain. Targetting DO certification, only certified hardware will be of concern though. To aim at making a fully featured RT kernel, the drivers for non-certified hardware will need expertise, and some of the job might be done in the meantime.
The scheduler does have a superseded O(1) algorithm. The new algorithm, actually diverging at O(ln(n)), is however much faster than the O(1) for all real-life cases (less than 4G processus). Again, no concern here.
The malloc will need careful audit, then. This will be tedious but I am confident, as Linux use has already spread so that I am sure the audit is already fairly advanced.
Next idea lies where all the error and exceptions handling functions are. These are the other possibility of undesirable unbounded latency.
Then what ? After all the work in between have been considrerd, I think we are then almost done. Provided no-one uses the Joystick port any longer (that one can only be driver via active wait), we have then dealt with all things a processus and drivers can do : syscalls, memory, read/write, interrupts, errors...
The project in which all this work will be issued is to be announced shortly...
lundi 30 novembre 2009
mercredi 18 novembre 2009
OpenBSD's bleeding edge pf
Even though I am no networks specialist, I have been involved in the business of having to understant how OpenBSD's packetfilter, aka pf, does round-robin load balancing.
The why of this expertise was quite straightforward : as pf does round-robin exactly well and balances the load exactly as expected, the first ever target, I mean the first target when the rules are set, has been found not to be the first in the list. This remark possibly matters 0.001% of all potential pf users, but I have then been required to check pf's predictability - an unpredictable pf's first was the most seriously fact feared...
This holds for OpenBSD 4.2, ie a fairly old one, but pf code has hardly changed since, and I have not seen any change in the lines involved here.
What happens is that, using BSD's TAILQ structures and macros, pf does choose the first in the list, then iterates before selecting the target. In a word, the first target that the load balancing hits is the second in the list. It is fully predictable and safe : a behaviour well in OpenBSD's tradition.
In the end, I had to patch the program that generated our pf rules, so the first does come first in the production system...
The why of this expertise was quite straightforward : as pf does round-robin exactly well and balances the load exactly as expected, the first ever target, I mean the first target when the rules are set, has been found not to be the first in the list. This remark possibly matters 0.001% of all potential pf users, but I have then been required to check pf's predictability - an unpredictable pf's first was the most seriously fact feared...
This holds for OpenBSD 4.2, ie a fairly old one, but pf code has hardly changed since, and I have not seen any change in the lines involved here.
What happens is that, using BSD's TAILQ structures and macros, pf does choose the first in the list, then iterates before selecting the target. In a word, the first target that the load balancing hits is the second in the list. It is fully predictable and safe : a behaviour well in OpenBSD's tradition.
In the end, I had to patch the program that generated our pf rules, so the first does come first in the production system...
mardi 8 septembre 2009
L'embarqué au service de la sécurité ?
Quelques réflexions sur la sécurité routière :
Au moment où les tristement célèbres boites noires, témoins ultimes des éléments techniques précédant les incidents de vol dans l'aviation, se font frapper d'obsolescence, n'est-il pas temps d'envisager l'utilisation des idées qui ont été à l'origine de leur création, à savoir l'analyse précise des événements afin d'accroitre la sécurité, au profit de la route ?
En partant d'un format ouvert, signé pour cacheter le contenu, d'événements datés et archivés à chaque événement ressemblant à un accident, le but serait de proposer un dispositif, techniquement dédié à l'analyse des événements pré-accident, dont le but serait principalement de détailler la responsabilité de chacun des petits oublis et/ou libertés avec le code de la route. Ceci pour fournir 2 éléments :
* Un compte-rendu exact des responsabilités engagées,
* Un relevé fiable des causes d'accident.
Ceci afin de répondre à 2 besoins : la responsabilisation des chauffeurs, d'une part, avec comme principal moteur la conduite sécuritaire car le dispositif ne serait activable qu'en cas d'événement accidentel, et un relevé juste et exhaustif des statistiques des événements déclencheurs d'accident, pour que les forces de l'"ordre" ne soient plus tentés de dire d'un accident pour lequel aucune case ne peut être cochée : "C'est la vitesse" !
Parce que j'en ai marre de serrer les fesses à chaque fois que, signifiant mon intention d'aller tout droit, je me sens suivi par un hurluberlu qui croit dur comme fer que comme la plupart des gens, je tourne à droite en omettant mon clignotant !!!
Au moment où les tristement célèbres boites noires, témoins ultimes des éléments techniques précédant les incidents de vol dans l'aviation, se font frapper d'obsolescence, n'est-il pas temps d'envisager l'utilisation des idées qui ont été à l'origine de leur création, à savoir l'analyse précise des événements afin d'accroitre la sécurité, au profit de la route ?
En partant d'un format ouvert, signé pour cacheter le contenu, d'événements datés et archivés à chaque événement ressemblant à un accident, le but serait de proposer un dispositif, techniquement dédié à l'analyse des événements pré-accident, dont le but serait principalement de détailler la responsabilité de chacun des petits oublis et/ou libertés avec le code de la route. Ceci pour fournir 2 éléments :
* Un compte-rendu exact des responsabilités engagées,
* Un relevé fiable des causes d'accident.
Ceci afin de répondre à 2 besoins : la responsabilisation des chauffeurs, d'une part, avec comme principal moteur la conduite sécuritaire car le dispositif ne serait activable qu'en cas d'événement accidentel, et un relevé juste et exhaustif des statistiques des événements déclencheurs d'accident, pour que les forces de l'"ordre" ne soient plus tentés de dire d'un accident pour lequel aucune case ne peut être cochée : "C'est la vitesse" !
Parce que j'en ai marre de serrer les fesses à chaque fois que, signifiant mon intention d'aller tout droit, je me sens suivi par un hurluberlu qui croit dur comme fer que comme la plupart des gens, je tourne à droite en omettant mon clignotant !!!
mardi 18 août 2009
Un NetBook sympa...
Depuis l'annonce de l'OpenPandora, je me suis mis à voir en ce curieux engin un fort sympathique instrument à développer en toutes occasions, avec une taille juste bonne pour la poche, et un clavier pensé pour la contrainte du compromis que les doigts de l'utilisateru ne se miniaturise pas...
Toujours sur la même techno sur base ARM (un ancien de Cambridge comme moi est nécessairement sensible à leurs miracles), le TouchBook de Always Innovating...
Allez, plus qu'à rêver de la même chose sur base Cortex A9... En attendant, jolie bête : Reprenant la taille des NetBooks les plus sympas à mon avis (9" : en dessous, la résolution de l'écran chute à un simple WVGA, au-dessus on ne gagne plus rien de concret), ajoutant une jolie innovation sur le coup du clavier détachable, ce combiné tablette-ordinateur sous Linux est le gadget de geek qui me fait le plus envie à l'heure actuelle !
http://www.alwaysinnovating.com/touchbook/
Toujours sur la même techno sur base ARM (un ancien de Cambridge comme moi est nécessairement sensible à leurs miracles), le TouchBook de Always Innovating...
Allez, plus qu'à rêver de la même chose sur base Cortex A9... En attendant, jolie bête : Reprenant la taille des NetBooks les plus sympas à mon avis (9" : en dessous, la résolution de l'écran chute à un simple WVGA, au-dessus on ne gagne plus rien de concret), ajoutant une jolie innovation sur le coup du clavier détachable, ce combiné tablette-ordinateur sous Linux est le gadget de geek qui me fait le plus envie à l'heure actuelle !
http://www.alwaysinnovating.com/touchbook/
lundi 20 juillet 2009
Latence, préemptibilité and al
C'est dit, je me consacre du temps cet été pour me "muscler" au niveau du scheduler et des éléments internes du kernel. Le but : apporter une petite touche avec l'esprit temps-réel. Je ne serai pas le premier à le faire (ni le dernuer j'espère), mais ce serait tellement chouette un kernel RT...
Si quelqu'un a un pointeur pour des analyses au sujet de FreeBSD sur ce point je suis preneur :-)
Si quelqu'un a un pointeur pour des analyses au sujet de FreeBSD sur ce point je suis preneur :-)
jeudi 11 juin 2009
Hors sujet
Petite parenthèse 100% hors sujet.
Dans l'actuelle mouvance philosophico-écologique, ne crachons pas sur ce qui est fait jusqu'ici, on a fait bien plus d'effort en 10 ans que pendant tout le reste de l'humanité, le tout grâce à une prise de conscience dont on finissait par désespérer.
Cependant, chassez le libéral, il revient au galop, tout s'est fait en se concentrant sur une seule donnée, puisque comme chacun sait notre monde perçu par les financiers n'existe qu'en 1 dimension... Et la dimension qui a été choisie s'appelle "CO2".
Or il est un domaine où la pollution autre que le CO2 a un aspect manifestement plus nocif et dommageable que le CO2 : les moteurs à combustion spontanée (nommés du patronyme de son inventeur "Diesel"). En effet, une étude suédoise attribue aux échappements du Diesel en Europe presuqe autant de morts par cancer du poumon que... l'amiante, interdite chez nous depuis quelques années déjà !
On pourra dire qu'il s'agit encore d'une avancée écologique, puisque les premiers touchés par les dommages en question sont les mammifères vivant en zône urbaine, à savoir les homo erectus citadinus, aussi les pires pollueurs de la planète : autorégulation...
Je n'adhère pas.
Exigeons la prise en compte des émissions de particules fines (non filtrées par les très mercantiles "Filtres à Particules") dans le calcul de la puissance fiscale et de la taxe pollution.
Dans l'actuelle mouvance philosophico-écologique, ne crachons pas sur ce qui est fait jusqu'ici, on a fait bien plus d'effort en 10 ans que pendant tout le reste de l'humanité, le tout grâce à une prise de conscience dont on finissait par désespérer.
Cependant, chassez le libéral, il revient au galop, tout s'est fait en se concentrant sur une seule donnée, puisque comme chacun sait notre monde perçu par les financiers n'existe qu'en 1 dimension... Et la dimension qui a été choisie s'appelle "CO2".
Or il est un domaine où la pollution autre que le CO2 a un aspect manifestement plus nocif et dommageable que le CO2 : les moteurs à combustion spontanée (nommés du patronyme de son inventeur "Diesel"). En effet, une étude suédoise attribue aux échappements du Diesel en Europe presuqe autant de morts par cancer du poumon que... l'amiante, interdite chez nous depuis quelques années déjà !
On pourra dire qu'il s'agit encore d'une avancée écologique, puisque les premiers touchés par les dommages en question sont les mammifères vivant en zône urbaine, à savoir les homo erectus citadinus, aussi les pires pollueurs de la planète : autorégulation...
Je n'adhère pas.
Exigeons la prise en compte des émissions de particules fines (non filtrées par les très mercantiles "Filtres à Particules") dans le calcul de la puissance fiscale et de la taxe pollution.
lundi 24 novembre 2008
La latence, tout est là...
Les efforts de Ingo Molnar ont été momentanément mis en attente avec la suppression du Big Kernel Lock apparu pour (de mémoire) le 2.6.27. Tout ça pour arriver (enfin) à maîtriser la latence.
Aujourd'hui, où en est-on exactement ? A part que la plupart des handlers se contruisent avec la problématique de latence en tête, il reste des approches contradictoires, ou plus exactement "nombrilistes" : si l'on veut que "son" driver soit temps réel à latence la plus faible alors il faut que tous les autres drivers aient une latence sous interruption maîtrisée (donc souvent en 2 parties) mais que l'on écrive son propre driver en monobloc... Rassurons-nous, la différence entre les deux reste très faible.
A voir en pratique...
Prochaine étape : tickless kernel sur OpneMoko et Pandora.
Aujourd'hui, où en est-on exactement ? A part que la plupart des handlers se contruisent avec la problématique de latence en tête, il reste des approches contradictoires, ou plus exactement "nombrilistes" : si l'on veut que "son" driver soit temps réel à latence la plus faible alors il faut que tous les autres drivers aient une latence sous interruption maîtrisée (donc souvent en 2 parties) mais que l'on écrive son propre driver en monobloc... Rassurons-nous, la différence entre les deux reste très faible.
A voir en pratique...
Prochaine étape : tickless kernel sur OpneMoko et Pandora.
Inscription à :
Messages (Atom)