cosmoff a écrit 66 commentaires

merci beaucoup pour ta réponse, je vais faire ca

iodine  ? je vois cette option nulle part dans man mount et man setcap

tu veux dire que mes shared memory ne sont plus deux int32_t mais juste une shared memory d'une structure comme:

struct{
int32_t ma_variable1;
int32_t ma_variable2;
}

et mon futex reveille mes autres processus quand je modifie la structure.

j'ai donc une seul shared memory, une seul structure, un seul futex avec N variables

Ca m'a l'air super bien, je ne vois aucun incovénient avec cette méthode.

oui avec une event loop c est pas mal ca me permet de retirer les futex, mais j'aurais donc N tubes pour N variables

merci pour vos messages,

-> je lance mon programme avec sudo chrt -f 99 ./a.out
-> je ne pense pas qu'il soit necessaire de passer sur du PREMPT_RT ou xenomai pour avoir un timer de 1ms avec une marge d'erreur seulement de 10%
-> pour moi le fait d'utiliser timerfd_create ou timer_create ou setitimer revient au meme.

j'ai remarqué que j'avais une erreur seulement de 2 à 3% (au lieu des 10 à 40%) quand mon systeme était stressé (avec le programme stress). On me renseignant un peu j'ai appris que le systeme pouvait entrer dans des niveaux de sommeil (suspend, hibernation), et lorsque l'interruption de mon timer se déclenche ca met un certain temps avant de pouvoir déclencher le handler associé. J'ai l'impression que le probleme vient de là.

Je vais donc essayer de changer certain parametre noyau. Peut etre retiré le mode tickless, mettre une frequence de timer à 1000Hz (au lieu des 250Hz par défaut) et essayer de retirer les états de sommeil de mes cpu

oui j'ai augmenté la taille du string et le systeme de rvalue a bien donné l'adresse ou se trouve la chaine de caractere, et n'a donc pas fait de copy

merci beaucoup pour vos éclaircissements

ok ca marche, j'ai basculé sur une console (ctrl+alt+F2), puis j'ai modifié le :
*tmp++ = 0;
en
*tmp++ = 0x00FF0000 (transparency + RGB)

et l'écran a basculé en rouge (mettre une sleep(1) juste avant la boucle car le terminal a tendance a ecrire des choses sur l'écran, notamment du noir)

pour la seconde question, je comprend pas trop le fonctionnement de taper directement sur l'adresse physique mais via une adresse virtuelle

le programme marche tres bien et il n'y a aucun débordement pile, il se termine correctement.

merci pour ta réponse, alors oui c'est du bidouillage mais c'est dans le but de me faire progresser avec le fonctionnement des pointeurs et de la logique de fonctionnement du code

yes merci énormément pour ta reponse t'as dit tout ce dont j'avais besoin de savoir !

merci pour vos réponses. Mais je me suis tres mal exprimé. Ma vrai question est comment udev.service arrive à transformer des fichiers qu'il trouve dans le réportoire /sys vers un fichier block qu'il place dans /dev. et lorsqu'on fait un open("/dev/sdb1"), comment le noyau sait que l'on parle d'une clée USB car pour le noyau les périphériques se trouve dans son répertoire /sys

merci pour vos réponses.

J'ai donc testé le code ci dessous :
void* callback1( void* t)
{
for (int i = 0; i < 1; ++i)
{

pthread_mutex_lock ( &mutexDeCosmoff );
printf("mutexDeCosmoff %i\n", ((char*)&mutexDeCosmoff)[16] );
count ++;
pthread_mutex_unlock ( &mutexDeCosmoff );
printf("mutexDeCosmoff %i\n", ((char*)&mutexDeCosmoff)[16] );

    }
    return NULL;
}

et j'ai en sortie
mutexDeCosmoff 0
mutexDeCosmoff 0

donc la valeur de mon mutex ne change pas que je fasse lock ou unlock

Alors j'adore Linux, j'utilise cet OS tout le temps, mais dire que windows plante sans arret c'est probablement du à des erreurs de l'utilisateur, d'ailleurs je peux faire facilement planter ma machine Linux en faisant n'importe quoi dessus. J'ai utilisé windows pendant des années et je n'ai jamais eu un seul probleme dessus.

Mais je te rejoins apres pour dire que Linux est génial ;)

c'est beaucoup plus claire merci d'avance pour vos éclaircissements

dsl mais je n'ai pas compris ton explication, tout ce que je vois c'est du code assembleur^{^}

merci pour vos réponses.

Ca marche avec le code :

char *str = "coucou\n";

asm("movq %0, %%rsi" : "=r" (str));

asm("movq $8,%rdx");
asm("movq $1,%rdi");
asm("movq $1,%rax");
asm("syscall");

ok merci beaucoup pour l'info

ok je me suis mal exprimé.

Je veux dire que le processus est bloqué par un dead lock. donc le processus est toujours actif mais il n'avance plus dans ses instructions

yes ton idée est bonne pour mettre mon écran en bleu. Ton pdf ne parle helas que du mode text graphic or moi je veux dessiner des pixels non du text. J'ai l'impression que utiliser la carte graphique est beaucoup plus compliqué que je ne le pensais. Tout ce que je vois sur internet c'est de passer a travers le bios pour dessiner des pixels.

je precise que j'utilise qemu pour simuler tout ca, n'est ce pas ca le probleme ?

effectivement toute la partie du code avec BP c'est de la magie noir que j'aurais du supprimé. Pour la premiere partie de ta réponse, je ne l'ai pas trop comprise. la carte vidéo est mappé en mémoire donc j'utilise tout simple segment << 4 + offset pour arrivé sur la bonne case mémoire physique, et les différentes combinaisons pour acceder a cette mémoire physique est tres grande .

pour les sources que j'utilise : Texte du lien mais j'ai dépassé le cadre du tuto pour ce que je veux faire

yes je veux dessiner des pixels, sur le premier lien que tu m'as envoyé il utilise dans son code des interruption logiciel et c'est le bios qui fait tout le travaille. Moi je veux faire ca sans bios, et ton second lien est parfait pour ce que je veux faire. Mais j'ai fait exactement ce que le premier lien préconisé dans mon exemple de code, d'ou mon blocage

merci pour vos réponses tres complete.

Ce qu'il me pose probleme c'est que la mémoire est sensé etre contiguë pour le developpeur. Or à un moment le tas va arriver vers la mémoire de la pile et il va y avoir un saut de 8Mo (taille de la pile) pour pouvoir recréer de la mémoire dans le tas

Le lien que tu m'as donné est vachement bien fait !

petite chose que je ne comprend pas. /dev/fb0 est fourni par le noyau, donc a chaque fois, je passe par le noyau pour afficher des choses à l'écran. admettons maintenant que je veux créer mon propre noyau, et je souhaite pouvoir afficher des choses à l'écran. ma carte vidéo est forcément connectée (directement ou indirectement) a des ports de mon CPU. Mais comment je peux faire avec mon propre noyau pour afficher des choses à l'écran.
Autrement dit comment je peux envoyer des data à ma carte vidéo avec mon propre noyau fait maison.

Merci pour vos réponses.

Je n'ai rien trouvé comme documentation sur mon systeme concernant rtc.

En effet j'initialisais l'alarme pour 00h00 et 30 secondes. Mais ca ne marchait toujours pas apres cette modification. en faite ca marche uniquement si j'initiliaise l'alarme avec RTC_ALM_SET puis je l'autorise avec RTC_AIE_ON. Ca me parait etrange l'obligation de faire dans cette ordre la. Avez vous une idée du pourquoi de cet ordre car sur la documentation rien n'est écrit a ce sujet mais peut etre que ca coule de source.

j'ai donc modifier ca :
```
memset(&rtc_tm, 0, sizeof(struct rtc_time) );
rtc_tm.tm_sec = 0;
rtc_tm.tm_min = 14;
rtc_tm.tm_hour = 6;

if ( ioctl(fd_open, RTC_ALM_SET, &rtc_tm) < 0 )
{
    printf("ioctl RTC_ALM_SET : %i\n", errno);
    exit(1);
}

 if( ioctl(fd_open, RTC_AIE_ON, NULL) < 0 )
{
    printf("ioctl : %i\n", errno);
    exit(1);
}