David Marec a écrit 472 commentaires

Sans parler des gens d'OpenBSD, qui mangent les bébés.

Le sujet n'est pas les montres connectées.

Ce n'est pas non plus le desktop.

» Les Blobs sont sur la plage
» Ils s'enfoncent dans le sable
» Ils font trembler la terre
» Font déborder la mer
» Ils vibrent et ils frétillent
» Ils attaquent, ils attaquent
» Les Blobs Les Blobs
» Les Blobs sont sur la plage
» Leur graisse rouge se dandine
» Tout comme des plum puddings
» Ils suent leur cornets de frites
» Par toute leur cellulite
» Leur ventre se gonfle de bière
» Ils m'attaquent par derrière

--
(ctmetcsdc) Ludwig von 88

Il ont bien gravé en 7nm de chez TSMC.

Ils annoncent l'arrivée d'un « testchip » en 7nm fin 2018. Mais, je ne trouve aucun compte-rendu à ce sujet depuis.

La seule autre référence que je trouve sur le site pour du 7nm concerne les puces Versal

Sacré bestiole, soit-dit en passant.

Ils n'en parlent pas sur la page du produit.

Ni même dans les documents d'architecture. La finesse de la gravure ne concerne surement qu'un ou plusieurs composants de ce produit.

Pour info les dernier FPGA de Xilinx sont gravés en 7nm

Curieux, sur leur site, on ne trouve rien en dessous du 16nm.
Pour les SOC, mis à part les tout derniers UltraScale+, on a droit à du 28nm en général.

Qu'est ce qui est inclus dans le initrd avec cette méthode ?
Il ne serait pas plutôt conseillé de monter le rootfs en RAM pour un live-CD ?

Le /dev/ro est hard-codé, c'est gênant (risque de ne pas retrouver le point de montage s'il y a d'autres CDs de montés, je pense), mais on verra pour améliorer ça plus tard.

Avec une étiquette (label ou volume name), /dev/disk/by-label/ ?

#fstab
tmpfs /var tmpfs defaults 0 0

Je ne sais ce que Debian a besoin, mais si il suit le FHS, il ne manquerait pas non plus /run et /tmp ?

Vous pouvez observer la publication d'un bon paquet de correctifs depuis la page intel en date du 12 novembre.

Attention, le chargeur d’amorçage — en particulier le loader.efi — a quelque peu bougé, faites gaffe quand même.

Un petit correctif à ce sujet vient de sortir, suivi d'une mise à jour du micro-code intel et de son Machine Check Exception on Page Size Change.

Bref, voici la 12.1p1.

Je n'aime pas la façon dont le standard C89 est rédigé,

Justement dans C11, c'est rédigé différemment, lorsque l'on a affaire à un UB, c'est dit explicitement dans l'article concerné.

Je ne prendrais pas ça à la légère,

Ce n'est certes pas à prendre à la légère, le contenu des tableaux dépend du sens du vent. Mais c'est parfois voulu.

c'est que les compilateurs en profitent pour faire des optimisations de code assez tordues.

C'est le cas de la plupart, voire toutes, les UB déclarées sous GCC. Il se permet souvent de zapper tout le code qui contient une UB, mais jamais dans ce cas précis, c'est à dire avec un tableau.
Lorsque la variable peut-être collée dans un registre, il va se comporter différemment.
- mais je crois que la norme mentionne ce cas précis. -

J'insiste, il y aura une fuite de mémoire à chaque exécution te ce programme, cette fuite sera résorbée par le système d'exploitation à chaque fin d'exécution, mais fuite de mémoire il y aura.

Vous essayez surtout de trouver une définition de la "fuite mémoire" qui vous donnerait raison.

Je reconnais que l'exemple est un peu tordu dans le sens où, de toutes façons, on ne peut pas faire grand chose en C une fois que le main() est terminé,

On peut laisser traîner des choses comme des tubes nommés.

Attention, j'ai bien dit "Sous Linux etc.", ce n'est absolument pas le cas sur la plupart des OS dit "temps-réel" - surtout ceux qui tournent sur des archi sans MMU. -

mais si le code dans le main() était dans une fonction f() qu'on appelait à la chaîne, peut-être serais-tu plus enclin à la voir.

T'inquiète, je sais ce qu'est une fuite mémoire, une vraie. J'ai vu des gens coder en Java.

J'insiste, section A.6.2 Undefined behavior

Qui se réfère à ceci,

if an object that has automatic storage duration is not initialized explicitly, its value is indeterminate

même formule en C11:

6.7.8 Initialization
10 If an object that has automatic storage duration is not initialized explicitly, its value is
indeterminate.

La "synthèse" liste ce cas, tout en faisant référence à des articles … où l'UB n'est pas indiquée.

Je ne connais aucun compilo qui s'autorise à invoquer un démon nasal dans ce cas, et où dev/mem ne fonctionnerait pas.

Ici, on a bien de la mémoire pour l'input et l'output (mémoire de la pile), mais l'appel à mafonction va engendrer la lecture du tableau input qui n'a pas été initialisé, ce qui va provoquer un comportement non-défini,

Non, la valeur est «indeterminée», ce n'est pas un cas d'«undefined behavior».

Mais on aura oublié d'invoquer free afin de libérer la mémoire allouée pour input et output, > créant une fuite de mémoire qui est à-peu-près passible de la peine capitale pour un programmeur C.

Ben non.
Vous pouvez lancer ce programme autant de fois que vous voulez sous Linux, sous Windows ou BSD, vous ne verrez pas la moindre fuite de mémoire.

Attention, sizeof est un opérateur, pas une fonction. Il ne devrait y avoir de parenthèses que si l'on cible un type et non une variable (unary-expression).

sizeof array / sizeof array[0]

Ensuite, passer au stade supérieur, à coup de zfs send | ssh zfs receive.

je cherche un script shell pour copier un gros dossier

• transfert:

$ scp -r gros_dossier nouveau_server:

qui puisse envoyé un mail si un probleme se produit pendant le transfert(hors coupure reseau)qui ce fera la nuit et sera lancer par un cron.

• cron job:

MAILTO="admin@linuxfr.org"
00 00 * * * root /usr/bin/scp -r gros_dossier nouveau_server: >/dev/null

Je n'étais pas sûr d'avoir compris le sens de ta demande et je suis parti du mauvais côté de l'interprétation

Je dois avouer que je l'avais compris de travers aussi.
De fait, je trouve l'idée très pertinente.

Xilinx propose les Zynq qui dans le même SoC embarque un FPGA et un processeur ARM, mais le processeur accède au FPGA via un un bus classique comme il accéderait à un autre type de contrôleur.

En fait, ils peuvent aussi se partager de la mémoire, ce qui simplifie la communication.

D'un autre coté, est arrivé avec la 4.19 le DFL, porté par Intel.

J'ai fini par mettre Linux qui fonctionne plus ou moins.

C'est à dire ?

J'ai regardé dmesg et j'ai pas mal d'erreurs dont :
…

Ce n'est pas gênant, c'est l'ACPI qui empêche un module natif d'accéder à une zone qu'il a réservé (et donc de se charger).

Vous pouvez autoriser les pilotes en jouant de acpi_enforce_resource=lax, mais ça peut réserver des surprises.

Pourrais-tu m'indiquer comment debug l'ACPI ?

En suivant le lien que j'ai donné  ? ;)

Cela se traduit par un chargement très long lors de l'installation / démarrage de l'OS et des freezes

Et sous Linux ?
Pour déterminer l'origine de problème, et peut-être le corriger, il sera intéressant de débugger l'ACPI.Car ce standard touche un peu à tout.

Je ne sais pas pourquoi j'ai ce problème qui est survenu subitement

Une configuration EFI/BIOS qui a changée ?
Une mise à jour de l'ACPI ?

Il y a seulement Linux que je peux utiliser, car il est possible de ne pas activer l'ACPI.

Ou les ⋅BSD.

Mais c'est un autre problème, car cet ordinateur a de piètre performance sur Linux contrairement à Windows 7

Ce qui peut aussi être du à l'absence d'ACPI. Un périphérique qui, en l'absence des tables et autres infos qui le concerne, tournerait en sous-régime ou les états ACPI coincés en mode low power (parfois configurés dans le BIOS).

Je suis donc contraint d'utiliser les pilotes libres qui sont vraiment, mais alors vraiment pas performant.

Voire un problème d'horloge.

Bof, moi la question que je me pose, c'est ce que dit la norme à ce sujet.

Que l'on accède à une variable hors de sa portée, c'est un cas d' undefined behavior.

If an object is referred to outside of its lifetime, the behavior is undefined. §6.2.4/2

C'est pourquoi ce code n'est pas un exercice de langage C.
Je le considère comme un exercice pour expliquer le mécanisme des fonctions et de leurs piles, voire de l'espace mémoire utilisateur.C'est même un classique.
De mon point de vue, c'est la raison pour laquelle il est important de savoir pourquoi la valeur de i est malgré tout déterminée sur les architectures/OS les plus courantes.

Le fait est que le C et le C++ doivent être les seul langages (sans intégrer directement de l'assembleur) dans lequel on peut écrire et compiler de telles choses.

Si elle ne dit rien, on a effectivement un comportement indéterminé

Au contraire, c'est parce qu'elle le dit que c'en est un. Cela aurait pu être unspecified ou implementation-defined voire invalide.

D'ailleurs, tu le dis toi-même, il semble que quand les optimisations sont activées, ça ne marche plus pareil

C'est plus que ça.
Les compilateurs vont faire ce qu'ils veulent de ce code, même sans optimisation.
Ils peuvent le réduire à :

int main(void)
{
*((int*)(0))=0; // crash
}

si ça leur chante.

Mais on sort du sujet de l’exercice, AMHA.

Et pourquoi cela ne marche pas ?

qu'est ce qui "marche" selon vous ?

Le mot clé static ne rend pas la variable j valable pour tout le programme ?

Non, il étend la portée de la variable au fichier qui la contient.
De fait, elle ne peut plus alors être allouée sur la pile.

Le comportement n'est pas prévisible,

Si, il l'est, le résultat sera "0" ou quoi que soit écrit dans la première variable (ici i) de la fonction zero.
- la ou les variables selon l'empreinte mémoire du type de celles -ci. -

C'est un exercice pour expliquer le fonctionnement de la pile du thread d'un processus.

Attention, il suffit d'activer les optimisations pour que ça ne fonctionne plus.
( les variables qui ne font rien vont disparaître et les fonctions aussi, du coup).

on ne sait pas ce qui sera à stocké à l'adresse où était la variable locale i.

Il s'agit de ce qui se trouve sous le pointeur de pile (stack pointer), donc de l'état de la dernière variable 'locale' (au type près) de la dernière fonction appelée.

On ne sait pas si cette adresse sera accessible

Elle le sera.

Ça m'a l'air surtout plus proche de capsicum voire de cloudabi.

A noter que le prochain « sommet » Yocto se déroulera la semaine prochaine à Lyon, à la suite de la conférence linux embarqué.

la vidéo que tu lies est faite par un type random

Ce n'est pas un « type random », mais un mâle alpha.

Un autre cas est la variable partagée, mais dans ce cas il va souvent falloir ajouter les mutex pour gérer les accès concurrents ce qui n'est pas ce qui va assurer les meilleurs performances.

C'est pourquoi je cherche autant que possible à utiliser des pipes entre les threads. C'est une solution plus légère pour gérer la concurrence.