Damien Lespiau a écrit 35 commentaires

Oh mais Bernard est un gros tire-au-flanc, ce n'est plus un secret. 15 pauses café par jour et la petite sieste d'1h dans les toilettes après manger. Le reste du temps il déambule dans les couloir en racontant des blagues pourries. Quant a Monique, mieux ne vaut pas s'attarder, cela risquerait de mal tourner...

Je viens de retrouver du code que j'avais fait il y a quelques mois.

#ifdef ARCH_X86_64
static inline guint64 counter_read_time(void)
{
guint64 a, d;
__asm__ __volatile__ (
"rdtsc\n\t"
: "=a" (a), "=d" (d)
);
return (d << 32) | (a & 0xffffffff);
}
#elif ARCH_X86
static inline guint64 counter_read_time(void)
{
guint64 l;
__asm__ __volatile__ (
"rdtsc\n\t"
: "=A" (l)
);
return l;
}
#endif

static inline guint64 counter_elapsed(guint64 t0, guint64 t1)
{
return t1 - t0;
}


et ça s'utilise avec :

guint64 start, end, cycles_nb;
start = counter_read_time();
{
/* code à mesurer */
}
end = counter_read_time();
cycles_nb = counter_elapsed(start, end);


Sur x86 tu peux utiliser le timestamp counter (le fameux registre TSC et son instruction rdtsc) pour connaître le nombre de cycles CPU depuis son démarrage. Il faut se faire des petites fonctions autour de cette opération pour avoir un merveilleux compteur.

Pour du code, on peut se reporter à http://www.fftw.org/cycle.h

2 défauts :
- sur des systèmes SMP, les différents CPU peuvent avoir des TSC avec des valeurs relativement différentes
- Avec des processeurs qui changent de fréquence dynamiquement, il est pas immédiat de déduire du nombre du cycles un temps.

J'avais trouvé un pdf vraiment intéressant avec des considérations sur l'utilisation du registre TSC pour les mesures de performances : http://www.cs.toronto.edu/~demke/469F.06/Lectures/Lecture5.p(...)

Poster ce que le Makefile dit vraiment, parce que, par exemple, un noyau 2.6 ne peut pas te dire de faire make dep.
damien@fusion:~/src/linux-2.6$ make dep
*** Warning: make dep is unnecessary now.


#!/bin/bash

var1="toto1 toto2 toto3"
var2="tata1 tata2 tata3"

tab_var1=($(echo $var1))
tab_var2=($(echo $var2))

for i in `seq 0 $[${#tab_var1[@]} - 1]`; do
    printf "%-10s %s\n" ${tab_var1[i]} ${tab_var2[i]}
done


Je crois que set mouse=a en plus dans ton ~/.vimrc peut marcher !

- une exception "page fault" arrive sur le CPU vers cpm_uart_start_tx+0x4c (c'est là que Linux est sensé mettre à jour les structures de données de la MMU pour mapper la page à laquelle on veut accéder).

- Pour une raison qui m'échappe (je ne connais pas cette architecture), la demande de map est jugée mauvaise et donc handle_page_fault appelle bad_page_fault (par l'intermédiaire de do_page_fault).

- c'est ce bad_page_fault qui affiche "kernel access of bad area" (arch/ppc/mm/fault.c).

- linux termine le processus fautif (init) en lui envoyant un SIGSEGV (11)

- il est tout à fait possible que le comportement que tu observes seulement avec le process init et pas avec ton petit programme vienne de l'initialisation du port série faite par init (genre le set_termios là) ce qui pourrait mettre le driver dans un état différent que ton petit test.

- une question un peu naïve, mais on tente : es-tu sûr d'avoir toute les pages dont tu as besoin pour accéder au hard mappées ? je ne connais pas du tout ce hard, mais par exemple les registres auxquels on accède par la structure smc_t sont-ils sur la même page que le registre tx ?

- System.map permet de déduire les symboles dans lequel tu es si tu veux faire le décodage à la main, mais là, comme tu compiles avec les symboles de debug, le plus sage est de penser que ta pile est morte lorsqu'il essaye de décoder les derniers symboles

- Enlever ce warning : "WARNING: no UART devices found on platform bus!" en définissant le platform_device qui va bien pour ton SoC, il me semble que dans cettre structure il y a aussi les pages physiques que linux doit mapper pour ton device

- Il y a l'air d'avoir quelques versions différentes de l'UART cpm, bien s'assurer que l'on compiler le noyau avec la bonne config pour ton hard (cpm1, cpm2, ?)

- Le driver cpm_uart à l'air d'avoir pas mal changé entre la version 2.6.19 et la version actuelle, mettre à jour ce driver peut être une bonne idée ?

Bon courage !

Une piste : tout Gnome estt fait en C "objet" à base de GObject !

Essaye de trouver des infos sur le net avec les mots glib et GObject. En particulier on peut regarder la documentation de la lib : http://library.gnome.org/devel/gobject/unstable/index.html

"module statique" et "où est mon .ko ?" ne vont pas très bien ensemble.

+ Soit tu compiles ton fichier C pour l'incorporer dans la grosse image du noyau (c'est ce que tu fais là). Dans ce cas, il y a un .o (le fichier C compilé avec un gcc -c, tout va bien) et l'image finale du noyau (Image, zImage, bzImage, ...) contient les symboles de ce fichier.

+ Soit tu compiles ton (ou tes) fichier(s) C pour faire un module qui pourra être chargé dynamiquement et dans ce cas tu auras à la fois le .o et le .ko

Maintenant, il reste la question de la configuration de la compilation.
- La variable obj-y contient la liste des objets à lier à la grosse image.
- La variable obj-m contient la liste des modules à compiler
- Les defines CONFIG_XXX contiennent l'information 'y' ou 'm' en fonction de ce que l'on souhaite faire (lier le module à la grosse image ou en faire un objet chargeable dynamiquement (= .ko))
- en général on écrit dans le Makefile :
obj-$(CONFIG_XXX) += mon_module.o
- Le fichier Kconfig permet de déclarer XXX pour qu'un make menuconfig t'affiche l'option
config XXX
    tristate "mon super module"
    depends on FOO && BAR
    help
     Poupou !
- un make menuconfig permet de configurer XXX (au choix "ne pas l'inclure" "l'include dans l'image du noyau" "faire un module") et tu dois avoir un CONFIG_XXX dans le fichier .config qui contient la configuration courante de la compilation
- si ce que tu veux faire est un module qui pourra se charger dynamiquement il faut avoir :
linux-2.6$ grep CONFIG_XXX .config
CONFIG_XXX=m

et là tout s'enchaîne, dans le Makefile, obj-$(CONFIG_XXX) devient obj-m += mon_module.o et kbuild sort un .ko

Il reste des petits détails, du genre un make modules_install pour installer les modules fraichement construits là où le noyau pourra les trouver avec un modprobe (INSTALL_MOD_PATH permet d'installer ces modules autre part que le chemin par défault ('/')) ou un depmod -a pour construire les fichiers qui décrivent les dépendances entre les modules.

On peut imaginer plein de moyens pour faire ce genre de choses :

- Le plus simple : un driver en mode caractère par exemple accessible par /dev/myeventmanager qui bloque sur un read(). Lorsque ton driver a besoin de signaler un event, il va utiliser le driver derrière /dev/myeventmanager pour débloquer le read et passer une structure du type

struct myevent {
    u32 type;
    union {
        u32 arg_type1;
        u16 arg_type2;
    };
};

au processus qui vient de se faire débloquer pour lui dire quel event on vient d'émettre. Biens sûr il est possible d'améliorer l'idée :

    - rajouter le support de select(), poll(), epoll()
    - se faire une API dans le driver associé à /dev/myeventmanager pour que le
      reste du noyau puisse envoyer facilement des events.
    - ...

- Le "vieux" moyen de faire ça est d'utiliser les signaux UNIX, le driver balance un signal lorsqu'il le souhaite à un processus qui c'est enregistré (par le moyen d'un open() ou d'un ioctl par exemple) au préalable

- On peut essayer d'utiliser une socket netlink.

- On peut tenter de regarder dans les nouveaux syscall pour supporter des events qui viennent du noyau :
    - kevent (aujourd'hui mort)
    - signalfd()

piiioufff ça en fait des solutions. Reste plus qu'a débroussailler tout ça.

Voui, en fait je n'ai peut être pas été très clair, mais c'est juste que ceux qui ont construit le CONFIG_SCSI_WAIT_SCAN n'ont pas voulu donner le choix de le désactiver. Il est automatiquement mis à 'm' dès que ses dépendances sont là. Libre à toi de changer ce comportement :p

Si tu regardes driver/scsi/Kconfig:

config SCSI_WAIT_SCAN
        tristate
        default m
        depends on SCSI
        depends on MODULES

ce qui signifie que SCSI_WAIT_SCAN sera a 'm' dès que SCSI et MODULES sont sélectionnés dans la config. Pour changer ça tu peux changer le "default m" et faire un make oldconfig.

Avant le changement:
$ grep SCSI_WAIT_SCAN .config
CONFIG_SCSI_WAIT_SCAN=m

Après le changement en "default n" et un make oldconfig :

$ grep SCSI_WAIT_SCAN .config
# CONFIG_SCSI_WAIT_SCAN is not set

Parler de " Pour bloquer les ping sur IPCop 1.3, " ne veut pas dire grand chose. IPcop n'est qu'un frontend web pour netfilter, le firewall de linux 2.4 (et supérieur, il n'est pas prévu de remplacer netfilter pour le moment)

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all ne fait que paramétrer le pile IP de linux à travers proc.

Plus d'info dans l'EXCELLENT lartc, chapitre 13

http://lartc.org/howto/(...)

en particulier ici où l'on retrouve icmp_echo_ignore_all par exemple

http://lartc.org/howto/lartc.kernel.obscure.html#AEN1492(...)

Sinon, connaissez-vous d'autres systèmes (hors Wiki) permettant d'obtenir ce que je souhaite ?

Il y a toujours le sempiternel Gettext, les tutoriaux sont nombreux, les utilitaires connus et très bien supportés en php. (par exemple il existe un plugin smarty-gettext pour le moteur de templates smarty). C'est vraiment un outil dédié à la localisation et qui a fait ses preuves... bref je recommande vivement Gettext, pas seulement pour ses programmes en C (disons C pour simplifer), mais aussi pour ses sites web !

happy gettexting ! :)

oui c'est bien pour cela qu'il faut les tester les obfuscateurs, un obfuscateurs qui se limiterais à ca (ie Automatic conversion of identifiers garbled by Java obfuscators) n'est pas un bon candidat pour protéger son code...

c'est pas parce que tu trouves le mot "obfuscators" dans les caractéristiques de Jad que tout de suites les obfuscateurs, c'est mort. Comme d'hab c'est plus facile de faire chier (écrire un obfuscateur) qui de trouver les parades (ce que fait Jad sur un léger détail)

enfin, bref

wééé les hash md5 wééé les requetes HTTP pour aller prendre les infos sur le web... mais ca ne résout rien du tout, tant que la personne peut décompiler le code et sniffer les paquets qui sortent à l'aide d'un simple tcpdump pour récuperer les infos (oui meme si elles sont cryptées, de toute facon ya le code java décompilé, tout bien comme il faut avec Jad ( http://kpdus.tripod.com/jad.html(...) ) pour le décrypter)

Bon alors le monde est-il aussi mauvais ?

NON !

comme suggéré plut haut, les obfuscateurs de code débarquent à la rescousse

http://www.acm.org/crossroads/xrds4-3/codeob.html(...)

apres le choix de l'obfuscateur est délicat, que est le mieux ? où trouver des "benchmark" d'obfuscateurs ? existe-t-il un dé-obfuscateur pour tel ou tel obfuscateur ? est-ce vraiment impossible de comprendre qqch avec le passage de tel obfuscateur et après décompilation avec JaD ?

bref, après, c'est quand même un peu de boulot :)

bonne chance

c'est étonnant, c'est pourtant bien les même racourcis que ratpoison, ca aurait du te sauter aux yeux :)

comme quoi les ll c'est vraiment bien fait ! quelle consistance érgonomique entre les différents softs !

Génial, c'est vraiment la place pour ce genre de choses... nous sommes surement pas mal à rentrer de soirée tard et bourré, cependant c'est peu etre pas la peine non plus de le signaler si bruyament..

enfin, moi, ce que j'en dis...

lol on ne laisse rien passer même pas à 6h30 du mat :) apres une douce nuit de java... (mais quelle merde ce truc (non ce n'est pas une tentative de troll)

on ne saurait que chaudement recommander la formation Debian GNU/Linux qui se trouve ici

http://people.via.ecp.fr/~alexis/formation-linux/(...)

en particulier la partie qui peut t'interesser

http://people.via.ecp.fr/~alexis/formation-linux/sid.html(...)

elle explique un passage en sid, le passage en unstable n'étant pas si différent

voila voila

réussir avec brio ses examens

avec qui ?

pardon...

Oui alors là, certains vont sans doute dire que je suis un des nombreux idéalistes qui trainent sur ce site, mais la simplicité de windows comparé à un desktop GNOME ou KDE est toute relative.

Pas de logiciel compliqué à installer pour les tâches de base sous linux, alors que sous win ce n'est pas toujours le cas, par ex le logiciel de gravure de win est ridicule comparé à un K3B dont la simplicité n'a d'égal que la richesse de ses fonctionnalités.

Idem pour les videos, qui _de base_ marchent très bien avec linux, le nombre de personnes faisant appel a moi pour faire marcher les filtres DirectShow sous windows est impressionant alors que ceux où j'ai installé une Mandrake (pour ne pas la nomer) n'on rien à faire.

Un autre exemple, je suis dans le bureau d'un association qui a eu besoin d'un pc qui marche. Je me suis dit que j'allais changer un peu, et paf une Debian Woody dans la gueule. Une fois bien configurée, aucune plainte, tout ce passe à merveille, l'enviroment leur parait tres naturel et ils n'ont aucun problème à l'utiliser (Ya meme des accros à Frozen-Bubble, il est dangereux ce jeu)

Voila voila

Zema

a priori, le mieux (le seul cas possible si on y songe réellement ?) c'est de laisser le 3ème disque en "spare" et il prendra le relai (reconstruction) lorsque l'un des deux disques tombera

Les couilles DE Picasso

non rien...

Il y a aussi des gens qui sont contents de leur délai :)

5 jours ouvrables à partir de la demande, j'ai pas vu mieux encore :p

42 jours... plus que la traversée du désert du christ, avec cet argument il y a moyen de se défendre ...