totof2000 a écrit 9656 commentaires

Il y a tellement de langages plus intéressants …. En plus, les derniers rebondissements entre Oracle et Google à propos des APIs m'ont rendu méfiant : Java sapu cépalibre.

Un résumé que le P.I aurai pu faire en 2 phrases :

"Je ne suis pas sufissamment calé techniquement pour comprendre les tenants et les aboutissants de cette faille. Les détais sont sur (lien), et si quelqu'un pouvait aider à décoder ce qui y est dit, il en est remercié d'avance."

Itil n'est pas un problème en soi : j'ai bossé il y a quelque temps dans une boite connue ou il n'y avait aucune organisation, pas d'ITIL, et franchement, c'était pire que ce qui a été décrit plus haut.

Le problème ce sont les gens qui gèrent : ceux qà qui tu accordes un petit pouvoir et qui usent à fond de ce pouvoir pour essayer de montrer qu'ils sont indispensables.

La faille aurait pu être résumée en une ou deux phrases ….

c'etait mieux avant.

Encore un réfractaire au changement.

fichier preseed

A priori c'est du debian like.

J'ai vu un technique avec DD mais ca implique d'écraser le disque.
dd if=/dev/sdaX of=/dev/null bs=1048576 conv=noerror

Avec cette commande, tu n'écrases pas le disque : if correspond au fichier d'entrée (ici ton disque dur), of correspond au fichier de sortie (/dev/null, c'est à dire nulle part). Là dans ton cas tu mets if=sdb1 pour ne parcourir que ta partition, ou sdb pour parcourir tout le disque.

Par contre ne fais pas de fsck sans démonter ton filesystem … Et surtout il faut le faire sur une partition, pas sur un disque (il est posssible que ta partition soit sur sdb, mais d'après tes logs je pense que ce soit sdb1 qui soit concerné.

Il y aurait il commande plus efficace, plus performante?

Moi ce qui m'inquiète c'est que le superblock soit touché :

I/O error while writing superblock

Tu devras peut-être passer par un fsck en utilisant une copie du superblock de ton fs. Il y a des techniques pour le faire. Ce n'est pas hyper compliqué, mais ce bn'est pas non plus trop évident quand on ne sait pas trop ce que l'on fait.

Comme dit auparavant, trouve-toi un disque de remplacement pour recopier tes données si c'est possible

Sinon, dans le genre outil permettant de récupérer un disque, il y a ddrescue.

un pet libre ?

Comment dans ce cas récupère-t-on les sources ?
```

(désolé, pas pu le retenir celui-là ...)

Ton alogithme me semble de loin similaire à ce que j'ai écris, il serait bien que tu l'écrive en formules et que tu le simplifie en suite.

Comme je l'ai dit c'est un truc "simpliste" que j'ai écrit à la rache vite fait le soir tard, c'est d'ailleurs pour ça que je n'en a vais pas vraiment parlé au début : je sais que je dois y revenir. Ce n'était pas l'objet initial de mon post, mais j'ai tenu à en parler histoire de clarifier certaines choses, notamment le contexte dans lequel je lis/écris.

Le problème c'est que tu parles d'index, de status, etc. et au final tu te retrouve avec 4 variables écrites par les deux routines, ce qui est une recette pour un désastres et qui t'oblige à suspendre les interruptions

3 variables modifiées par 2 routines : head, tail et status.

Pas besoin de statuts vide, plein, demi-vide ou demi-plein ;-)

Je t'avoue que celle-là j'en ai un peu honte : comme tu dis il faut que je le reprenne. Je me doutais que je pourrais m'en passer, mais la flemme de réfléchir sur ça lorsque j'ai codé mon truc (a 1h du matin on a pas toujours les idées très claires …). J'ai donc fait un truc "vite fait" parce que je voulais tester un autre truc qui avait besoin d'un buffer de ce genre.

En effet, il faut sauvegarder le SREG avant de désactiver les IT pour ne pas perdre le SREG

Soit j'ai mal compris, soit sreg est sauvegardé par le hard.

Je conseille de ne surtout pas réactiver les interruptions dans les routines d'interruption en utilisant ces macros si on ne sait pas gérer les interruptions imbriqués ("nested") et attention à l'explosion de la pile avec la réentrance… etc

Je ne compte pas non plus le faire, c'est déjà assez compliqué comme ça.

Pour désactiver les interruptions dans le gestionnaire d'interruption tu as sans-doutes raison d'insister sur ce point, j'imagine qu'un avr est trop petit pour avoir un interrupt controller qui gère les priorités entre les interruptions.

D'après la doc AVR :
When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled. The user software can write logic one to the I-bit to enable nested interrupts. All enabled interrupts can then interrupt the current interrupt routine. The I-bit is automatically set when a Return from Interrupt instruction – RETI – is executed.

Les It sont désactivées si tu ne les réactives pas lors du traitement des It.

Au temps pour moi, J'aurais plutôt dire "on pouyrrait réduire notre déficit".

en fait à l'origine, je voulais éviter de désactiver/activer les it dans ma boucle principale pour éviter que ça "bagotte" et de perdre des interruptions, mais en m'arrangeant pour "endormir" mon processeur dans la boucle principale, ça devrait limiter la casse.

Euh .. erreur dans cette partie :

pour le vidage je récupère ma valeur, et je modifie mon index head ensuite Le détail :

• je teste la variable status pour voir si mon buffer n'est pas vide. S'il n'est pas vide, je lis mon buffer en récupérant l'élément a l'endroit pointé par buff + head.
• Ensuite, Je compare l'index tail head à la taille du buffer (qui elle ne bouge jamais) : si index=taille de buffer-1, je positionne l'index à 0. Sinon, j'incrémente cet index.
• Ensuite je compare head et tail: s'ils sont égaux, ça signifie que mon buffer est vide. Dans ce cas je positionne le status à vide. Sinon, je positionne le status à non vide.

Est-ce qu'un modérateur pourrait corriger ? Sinon ça n'a pas de sens.

Avant de continuer, je vais donner une petite explication sur la façon dont je remplis/vide mon buffer, ce sera plus simple et plus compréhensible. Je n'ai pas le code de gestion du buffer sous la main pour le moment mais voilà en gros ce que je fais :

Si tu regardes bien ma structure, j'ai une variable status dans mon buffer. Cette variable peut prendre plusieurts état : vide, non vide (équivalent à non plein), et plein.

J'ai défini un truc du genre :

#define BUFF_EMPTY 0
#define BUFF_NON_EMPTY 1
#define BUFF_NON_FULL BUS_NON_EMPTY
#define BUFF_FULL 2

Lorsque le buffer est vide, cette variable est à l'état vide. Lorsquer je remplis mon buffer, cette variable passe à l'état non-vide. Lorsque je le vide, elle passe à l'état non plein (qui est la même chose que non vide).Si je détecte après ajout d'un élément que mon buffer est plein, je positionne cet indicateur à plein. Si je détecte après vidage d'un élément que mon buffer est vide, je positionne cet indicateur à vide.

Pour le remplissage, j'ajoute mon élément dans le buffer, et je modifie l'index tail ensuite Dans le détail ça donne :

• je teste la variable status pour voir si mon buffer n'est pas plein. S'il n'est pas plein, je remplis mon buffer en ajoutant l'élément a l'endroit pointé par buff + tail.
• Ensuite, Je compare l'index à la taille du buffer (qui elle ne bouge jamais) : si index==taille de buffer-1, je positionne index à 0. Sinon, j'incrémente cet index.
• Ensuite je compare head et tail: s'ils sont égaux, ça signifie que mon buffer est plein. Dans ce cas je positionne le status à plein. Sinon, je positionne le status à non plein.

pour le vidage je récupère ma valeur, et je modifie mon index head ensuite Le détail :

• je teste la variable status pour voir si mon buffer n'est pas vide. S'il n'est pas vide, je lis mon buffer en récupérant l'élément a l'endroit pointé par buff + head.
• Ensuite, Je compare l'index tail à la taille du buffer (qui elle ne bouge jamais) : si index=taille de buffer-1, je positionne l'index à 0. Sinon, j'incrémente cet index.
• Ensuite je compare head et tail: s'ils sont égaux, ça signifie que mon buffer est vide. Dans ce cas je positionne le status à vide. Sinon, je positionne le status à non vide.

C'est au moment où tu vas calculer ton "sz" que ça va partir en live:

Comme tu le vois, je ne calcule pas de taille en tant que telle, par contre je pense que la comparaison entre tail et head équivaut à un calcul de taille (il faudrait juste voir comment le compilo génère le code assembleur dans ce cas pour en être sur).

si tu es en train de le calculer, et que l'écriture en mémoire n'est pas finie (par exemple), que ton IT claque, tu vas calculer un "freesz" qui peut être complètement faux!

C'est pour ça que je me demande si je ne devrais pas vider mon buffer sur interruption, pour m'assurer que les calculs se fassent sans accès concurrent potentiel.

Faire un truc du genre tester dans la boucle principale l'état de la variable status de ma structure, et si elle n'est pas vide, j'initie le transfert sur ma liaison série via It. Mais comme je n'ai pas pris le temps de réfléchir plus loin à cette partie, je ne suis pas vraiment sur de mon coup. Comme dit plus haut, il faudrait que je me refasse un petit schema du workflow.

Mais celà n'a pas l'air d'être le cas pour la "plus" simple raison que toutes ces variables sont des 16bits sur un AVR alors que ta cpu est en 8bits.

Bien vu, je n'avais pas pensé à ce détail.

Je ne peux que t'encourager vivement à lire le fichier .lss généré pour comprendre comment une instruction 'C' est compilée et optimisée

C'est ce que j'ai l'intention de faire de toute façon.

ps: par curiosité, quel est le micro que tu utilises et ça fait combien de temps que tu codes sur de l'AVR ou un micro 8bits?

J'utilise un atmega328. Ca fait déjà plusieurs dizaines d'années que je code sur du micro 8 bits (mais pas à plein temps) , mais jusqu'aujourd'hui, je ne faisais que de l'assembleur (sur ATTiny), donc un certain nombre de questions ne se posaient pas (notamment toutes ces histoires d'optimisation du compilateur).

Il y a-t-il un risque que l'interruption utilise une mauvaise valeur pour head ? C'est-à-dire entre le momen où tu calcules freesz et le moment où tu modifie tail.
-> Non je ne crois pas, au pire tu as un overrun du à un freesz sous-estimé.

Et bien si!

Mais à la limite on s'en fiche : je ne calcule pas la taille dans mon cas, je me contente juste de comparer tail et head pour savoir si mon buffer est plein. La seule chose que je risque, c'est de croire que mon buffer est plein alors qu'un espace a été libérée par la routine de lecture, ce qui n'est pas si grave que ça dans mon cas.

Il y a-t-il un risque que main utilise une mauvaise valeur de tail ? Idem, non je ne crois pas.

Et bien si!

Là encore je ne pense pas que ce soit grave : dans la boucle, il considèrera que le buffer est vide, alors que l'IT aura ajouté un caractère dans le buffer, et attendra la prochaine itération de la boucle pour voir qu'en fait il y a un caractère à émettre.

Quelques remarques en attendant que tes algos soit spécifiés et que l'on puisse te donner une réponse précise.

si ton interruption ne se fait pas interrompre, un volatile dans le code de l'interruption ne sert effectivement à rien.

Effectivement, vu que la routine d'it est censée sauvegarder le contexte d'exécution du programme interrompu.

un volatile dans le code "main" peut-être utile mais certainement pas suffisante (enfin faut voir ton algo toujours). Je conjecture que tu auras quand même besoin d'implémenter un mécanisme de type mutex pour te prémunir des problèmes de TOCTOU.

C'est pour ça que je n'ai pas encore spécifié mon algo: je "sens" qu'il y a un truc à faire à ce niveau (d'ailleurs tu as mis le doigt dessus, voir plus bas).

mettre volatile est souvent une fausse bonne idée. Je te laisse rechercher les références de Linus sur la LKML ;-) La démonstration suit…

Je pars du principe que volatile est utile, mais pas suffisant. si j'ai bien compris, volatile sert à "forcer" le compilateur à insérer une instruction de relecture de la valeur depuis la mémoire (pour des questions d'optimisation, le compilateur ne force pas la relecture de la valeur lorsque celle-ci est déjà dans un des registres du processeur).
Ca a son utilité lorsqu'une valeur est susceptible d'être écrite par un autre thread entre deux (ou plus de deux ) lectures successives (ou une interruption). Par contre ça ne règle pas les problèmes d'accès concurrents à une valeur, problème résolus par les mécanismes de mutex. L'un ne remplace pas l'autre, les deux ont une utilité différente.

Admettons que ton main ressemble à cela:

Ca y ressemble, au détail près que j'ai déporté la gestiuon du buffer dans des fonctions, appeléers par le main ou les routines d'IT.

Au niveu de l'interruption:

Tu en es pas très loin, au détail près que je ne calcule pas de taille, je me contente juste de comparer les index head et tail : s'ils ont la même valeur, ça signifie que le buffer est plein.

NB: c'est une implémentation naïve d'un buffer circulaire. Je n'ai jamais fait ce genre de chose, je te conseille quand même de consulter wikipedia avant ;-)

Mon implémentation n'est pas non plus très subtile non plus (j'ai fait au plus simple). Mais je peux (et devrai certainement) la modifier un peu (une idée m'est venu suite à vos remarques).

Donc nous avons ton interruption qui modifie tail et ton main qui modifie head.

La conclusion est bonne : l'interruption remplit, donc modifie le tail, et le main (et/ou une it) vide, donc modifie le head.

Il y a-t-il un risque que l'interruption utilise une mauvaise valeur pour head ? C'est-à-dire entre le momen où tu calcules freesz et le moment où tu modifie tail.

Comme je ne calcule pas (pour le moment) la taille, pas de risque.

Il y a-t-il un risque que main utilise une mauvaise valeur de tail ? Idem, non je ne crois pas.

Là par contre c'est peut-être possible. Le main est un classique : une boucle sans fin qui fait des trucs à chaquie itération. Comme je ne calcule pas de taille de buffer lors du remplissage, c'est peuit-être là que je devrais le calculer (pour déterminer le taux de remplissage de mon buffer et déclencher le transfert). Mais je pourrais simplifier en déclenchant le transfert dès que le buffer n'est pas vide.

Le problème se situe au moment où l'on calcule sz et freesz !!

Donc bref: tu copies tes volatiles dans des variables locales au début de ta routine pour être certain que tu n'accède pas à tes variables en ram directement.

Ca me parait une bonne idée.

Ton algo doit être conçu pour fonctionner sur des valeurs qui ne reflètent peut-être plus la réalité mais qui son cohérentes entre elles, pas pour fonctionner avec des valeurs certes actuelles mais qui changent au gré du vent/des lignes!!!

Ca me parait logique. Pour moi, le seul moment ou j'ai besoin d'une représentation réelle est lorsque le buffer est vide ou lorsqu'il est plein.

que se passerait-il si tail est accèdée en volatile et qu'une interruption fait wrapper tail et survient juste après que tu aies testé qu'il n'y a pas de wrap ? Oops un freesz < 0… ça sent pas bon hein… ;-)

C'est justement pour ça que je n'ai pas encore spécifié définitivement mon algo : j'avais senti cette mauvaise odeur de loin, mais pas eu le temps d'approfondir et de détailler la réflexion.

(Ma) conclusion :

pas besoin de mutex,

Je suis d'accord sur ce point.

surtout pas besoin de volatile, sous réserve que le code "main" soit dans une fonction séparée

Là je suis moins d'accord (en fait ça dépendra de mes choix) : je peux en avoir besoin si je calcule le taux d'occupation de mon buffer dans le main. Mais je crois que je vais éviter …

Maintenant si tu passes à plusieurs producteurs/consommateurs, ben ça se complique : ne le fais pas, utilise plusieurs buffers :p

Je ne compte pas le faire.

PS: je viens de me rendre compte que c'est l'inverse que tu veux faire, soit vider un buffer par une interruption. Cela revient au même.

Pas encore décidé : Ce qui est sur c'est que je remplis via une interruption. Par contre pour vider je me tate : soit je vide dans le main, soit je vide via l'interruption UART. L'avantage de l'interruption, c'est que je suis sur qu'elle ne sera pas interrompue durant son exécution. L'inconvénient : un peu plus de taf.

en tout cas merci pour ces indications qui me feront avancer. J'ai une ou deux idées que je vous présenterai si ça vous intéresse.

Ce matin il ne me proposait pas free, juste frère. Et je me suis rendu compte qu por qu'il me laisse le mot free, je devais faire un backspace.
Sinon, j'ai changé de téléphone récemment (passé d'un vieil android 4 à android 5.1), et il me semble que la cnfiguration a un peu changé (je n'ai pas trouvé immédiatement comment faire lorsque j'ai eu mon téléphone, et depuis je n'ai pas regardé de nouveau).

On donne actuellement sans contrepartie l'équivalent du budget du CNRS à des entreprises privées, dans le cadre du crédit impôt recherche.

Je ne dis pas que c'est forcément mieux.

Avec cette manne on pourrait donc doubler le budget du CNRS sans augmenter le budget de l'Enseignement supérieur et la Recherche.

On pourrait surtout réduire notre dette.

Autre axe d'économie : la course aux projets que se livrent les labo (ANR, Projets régions, etc.) prennent énormément de temps. Dans pas mal de cas les labo postule à des machins qui vont retenir 5% des dossiers, c'est débile. En revenant à un fonctionnement plus sain, c'est à dire en fournissant des dotations de fonctionnement au labo plutôt de les obliger à courir derrière des projets, on pourrait aussi gagner beaucoup de temps de recherche… à budget constant.

C'est effectivement une idée.

Bref, la question urgente n'est pour l'instant pas tellement s'il faut dépenser plus, car la marge de manœuvre pour mieux dépenser est énorme.

Mais ça j'en suis convaincu depuis longtemps. J'ai vu dans certaines administrations ou entreprises publiques (on trouve ça aussi dans le privé, mais ce n'est pasforcément aussi flagrant) des services qui bossaient de façon inefficaces ou archaique juste pour justifier le poste de certaines personnes. En réorganisant les services publics, je suis convaincu qu'on pourrait faire de sérieues économies sur ce genre de choses. On pourrait certainement ainsi payer des fonctionnaires dans les services qui sont réellement prêts à exploser (exemple : l'hopital ou la justice) sans forcément augmenter les dépenses de l'état.

Après on pourrait débattre pour savoir s'il vaut mieux avoir beaucoup de fonctionnaire (et donc beaucoup de service public) ou pas.

De toute façon,

ils font de l'argile : un mélange de la rache e de l'agile.

OK, mais il faut dans ce cas accepter d'en payer moins. Parce que c'est bien beau de demander une revalorisation des salaires des fonctionnaires, mais il est hors de question de payer des impots en plus pour pouvoir le faire.

Désolé pour les nombreuses fautes, mais j'ai écrit mon post sur mon smartphone qui s'entête à modifier ce que j'écris au fur et à mesure de la saisie, considérant que je fais des fautes alors que ce n'est pas le cas (j'ai eu du mal par exemple avec le mot free). J'ai corrigé quelques erreurs, mais je n'ai pas tout vu. Toutes mes excuses.

La la valeur de buff est stable, alors c'est head et tail qui sont susceptible d'être modifiés lors du remplissage ? Ce serait alors éventuellement ces deux variables qui devraient être volatiles.

Qu'en penses-tu ?

Je suis d'accord (c'est ce que j'avais mis il me semble dans mon post initial, mais je n'ai peut-être pas été clair, vu l'heure ou je l'ai fait).

Les scénarios :

• lors de la phase d'initialisation, je crée mon buffer (j'initialise la structure avec la zone mémoire à remplir/vider, et je positionne les variables tail et head, aisi que le status de mon buffer à Empty).

• j'initialise les routines d'interruption qui vont remplir le buffer (3 sources différentes).

• lorsque je reçois une interruption de l'une de ces 3 sources :

  • je lis l'état de 2 entrées
  • je lis le contenu d'un timer (14 bits utiles)
  • je merge les données sur 16 bits
  • je remplis mon buffer.

Note : quand je remplis mon buffer, je positionne la variable status à NON_EMPTY, et je la positionne à FULL lorsque je n'ai plus de place.

Pour info, sur mon microcontroleur, les interruptions ne peuvent être interrompues.

Dans ma routine principale, j'envisage de:
- tester le taux de remplissage du buffer (vérifier qu'il y a plus de N octets dispo).
- si le buffer est plein à plus de n%, je démarre la transmission des données sur une UART. L'idée serait de transmettre via interruption tant que le buffer n'est pas vide. Lorsque le buffer est vide, je stoppe le transfert (ais pour cette partie, je ne suis pas sur que ce soit la meilleure façon de faire, je n'ai pas encore les idées tout à fait claires, il est possible que je vienne à emettre via le a boucle principale).

Donc au final:
- dans mes interruptions de remplissage, je n'accède qu'à la variable tail (et à mon buffer)
- dans la boucle principale : je n'ai pas encore déterminé comment détecter le taux de remplissage. Probablement en lisant les variables head, tail et size de ma structure.
- si j'émets via interruption, je ne modifie que la variable head dans cette interruption. Comme une it ne peut être interrompu, je suis sur qu'il n'y aura rien de modifié pendant le déroulement de celle-ci
- si j'emets dans ma boucle principale, je suis suceptible d'être interrompu par une interruption de remplissage. Mais comme les variables modifiées pendant l'émission (head) n'est pas modifiée par la routine de remplissage. Par contre cette routile va la lire pour savoir si mon buffer est plein ou non. C'est là qu'il faut que je m'assure que ça ne pose pas de pb.

Dis-toi que sans volatile, un code peut-être optimisé de sorte à ne pas systématiquement lire ou écrire en mémoire vive mais soit récupérer une valeur toujours présente dans un registre ou postposer l'écriture en mémoire tant que le registre ne doit pas être libéré.

C'est bien ce que je pensais avoir compris, mais toujours avec un doute quelque part. Merci à toi, tu as levé mes doutes.

Ce sont les fonctionnaires eux-même qui le reconnaissent.

prévenir la concurrence malheureuse en multithread

Je n'ai pas cette problématique : c'est du développement sur microcontroleur AVR donc pas de multithread.

prévenir une optimisation malheureuse d'accès à la mémoire vive.

C'est surtout cet aspect qui m'intéresse aujourd'hui.

volatile ne permet d'éviter que les optimisations malheureuses d'accès à la mémoire vive.

Ca tombe bien, c'est ce que je cherche à faire ;)

Par contre, cela ne concerne que la variable en question…

C'est ce qui m'a semblé également, mais j'avais un doute d'ou mes questions.

dans le traitement de ce buffer, il y a typiquement un pointeur propre de parcourt initialisé avec le buff de ta structure

dans le traitement de ce buffer, il y a typiquement un pointeur propre de parcourt initialisé avec le buff de ta structure

Dans le parcours, j'accède de façon indirecte via *(buff + head) ou *(buff + tail).

et si volatile, toujours par une lecture de la mémoire vive, même si pour l'optimisateur un registre contient toujours la valeur)

Est-ce à dire que même si buff e ne bouge jamais (initialisé tout au début du code), j'ai intérêt à le déclarer volatile quand même ?

mais ensuite, que se passera-t-il ?

C'est ce que j'aimerais savoir …

Comme son nom l'indique, une interruption est susceptible d'interrompre le fil d'exécution où qu'il en soit

(il y a peut-être possibilité de protéger un petit groupe d'instructions, à la manière "atomique", mais je suis pas sûr…).

Dans ce cas précis, une interruption ne peut pas être interrompue. Mais malhereusement, il n'y a pas possibilité de générer une interruption logicielle (sauf à passer par un petit hack que je souhaite éviter), sinon, je pourrais passer par une interruption pour protéger le code en question. Mais je vois l'idée.

En tout cas, merci d'avoir pris un peu de temps pour répondre