David Decotigny a écrit 103 commentaires

L'important est ce paragraphe du man : << If the executable was linked with the flag "-rdynamic" (or, synonymously, "--export-dynamic"), then the global symbols in the executable will also be used to resolve refer-ences in a dynamically loaded library. >> Si je compile le programme qui suit :

/*
 * A compiler avec -rdynamic et linker avec libdl :
 *    gcc -o dladdr -rdynamic dladdr.c -ldl
 * cf man dlopen :
 *     If the executable was linked with
 *     the flag "-rdynamic" (or, synonymously, "--export-dynamic"),  then  the
 *     global  symbols  in  the executable will also be used to resolve refer-
 *     ences in a dynamically loaded library.
 */

#ifndef _GNU_SOURCE
#define _GNU_SOURCE 1
#endif

#include <stdio.h>
#include <dlfcn.h>

int main (void)
{
  void *addr = (void *) (main + 0x42);

  Dl_info info;
  int ret = dladdr (addr, &info);

  printf ("lookup %p:\n", addr);
  printf ("  retval: %u\n", ret);
  printf ("  fname:  %s\n", info.dli_fname);
  printf ("  saddr:  %p\n", info.dli_saddr);
  printf ("  sname:  %s\n", info.dli_sname);
  printf ("  fbase:  %p\n", info.dli_fbase);
  printf ("  pretty: \"%s+0x%x\"\n",
	  info.dli_sname, addr - info.dli_saddr);

  return 0;
}

de la façon suivante :

gcc -o dladdr -rdynamic dladdr.c -ldl

alors j'obtiens ce qu'on attend :

[pollindd] work/svn/2006/divers >./dladdr                                  1032
lookup 0x80486a6:
  retval: 1
  fname:  ./dladdr
  saddr:  0x8048664
  sname:  main
  fbase:  0x8048000
  pretty: "main+0x42"

Avec la GNU libdl (installée en plus-que-standard sous Linux), tu appelles dladdr depuis tes wrappers et ça devrait faire le boulot.

A vue de nez ça ressemble à un problème de pcmcia. C'est possible que ça coince pendant drivers/pcmcia/rsrc_nonstatic.c:do_io_probe(). Il me semble que le noyau devrait ecrire des choses apres le ":", genre "excluding blahblah..." ou "clean". Et si tu passes le parametre "probe_io=0" au module ?

Farpait !

Juste un detail : le kill -9 est peut-etre un peu violent, je sais pas s'il va bien plaire a vlc. Ca serait peut-etre bien de faire un truc genre kill $pid ; sleep 3 ; kill -9 $pid 2> /dev/null pour lui laisser une chance de terminer proprement.

C'etait le mode d'emploi pour passer pour un rigolo ;)

je me disais aussi que la ligne vlc ressemblait a qqch de connu...

Une solution qui marche peut etre (pas testee...) :

vlc .... &
pidvlc=$!
sleep .... &
pidsleep=$!

_trap_kill ()
{
trap "" KILL EXIT QUIT INT TERM
echo killing $pidvlc
kill $pidsleep
kill $pidvlc
sleep 3
sync
exit 0
}
trap _trap_kill KILL EXIT QUIT INT TERM

wait $pidsleep

Une solution a deja ete postee la :
http://linuxfr.org/~11010010/20437.html
Et un frontend python ici :
http://forum.ubuntu-fr.org/viewtopic.php?pid=159297#p159297

Yes ! Je crois que je vais l'adopter ;) !

Est-ce que tu pourrais rajouter une liste des enregistrements termines ou interrompus ? Ou alors 3 listes : une liste des enregistrements a venir, une liste des enregistrements en cours, et une liste des enregistrements termines/interrompus (avec possibilite de les supprimer du disque) ? Est-ce que tu pourrais rajouter la possibilite de donner (entrer a la main, recup automatique) des meta-info aux enregistrements (titre de l'emission, appreciation, ...) ?

Encore une... Tu pourrais juste rajouter un bouton "visionner" qui lance un viewer (configurable : pour moi ca sera xine pour les trucs deja sur disque, vlc pour les rtsp ;) sur le flux quand on clique sur une chaine, ou sur l'enregistrement quand on clique sur un enregistrement en cours ou termine/interrompu ?

Terrible !

Le truc qui me gene vraiment, c'est que atrm ne permet pas de virer l'enregistrement en cours s'il y en a un (atrm ne fait que supprimer le script de lancement dans /var). Ce que tu pourrais faire dans ton script, c'est passer en parametre a enregistrer.sh un nom de fichier unique. Quand ton script fait le at, il enregistre le numero du job attribué dans ce fichier (ligne JOBID=... par exemple). Des que enregistrer.sh lance vlc, il enregistre son pid (de enregistrer.sh) dans ce fichier (ligne PID=... par exemple). Ainsi, pour supprimer un enregistrement, ton script regarde atq d'abord, fait atrm si besoin, et s'il voit une entree PID=... dans le fichier unique, il fait un kill dessus.

J'ai du mal m'exprimer. Il ne s'agit pas de booter en 32bits pour acceder aux applis 32bits, puis de rebooter en 64bits pour avoir acces aux applis 64bits. Non, il s'agit de booter en 64bits, d'utiliser les applis 64bits quand on en a besoin, et de faire les chroot dans une installation 32bits pour acceder aux applis 32bits depuis le monde 64bits ! Un seul noyau necessaire, donc : le noyau 64bits.

Pour plus de details, voir par exemple : http://david.decotigny.free.fr/wiki/wakka.php?wiki=SargeAMD6(...)

En general non. Par exemple, si j'ai une debian x86_64, je ne peux pas directement installer des paquets pour la x86 (32bits) dans cette debian x86_64.

Par contre, ce que je peux faire, c'est installer une debian x86 (32bits) sur une autre partition ou dans un sous-répertoire de ma debian x86_64 (debootstrap par exemple sous debian). Une fois ma debian 32bits mise en place, je peux la gérer de façon transparente depuis ma debian x86_64 sans rebooter : installer des paquets, exécuter des programmes, etc. (dchroot sous debian).

J'imagine qu'avec une autre distribution que debian ça marche tout pareil. A l'origine cependant, je crois que dans debian ils avaient prevu de faire cohabiter les 2 environnements au sein d'une meme installation, donc avec la possibilite de jongler entre les paquets pour les 2 architectures (corrigez si je me trompe). Desormais, sous debian, il y a bien 2 distributions separees mais qui peuvent fonctionner ensemble sans probleme.

A noter que sur certaines installations de latex, les fontes "standard" (computer modern) sont bitmap-isées a l'ecran apres ps2pdf quand on utilise acrobat reader par exemple, mais ça passe bien a l'impression. Une methode pour reparer ça : http://web.gat.com/diag/pci/ltx2pdf.html (voir la "hard way").

D'autre part, pour integrer les fontes dans le pdf et faire un pdf qui plaise plus ou moins a une imprimerie, j'utilise les options suivantes :
# dvips -Ppdf -G0 -z -ta4 -D600
# ps2pdf -dPDFSETTINGS=/prepress -dCompatibilityLevel=1.3 -dMaxSubsetPct=100 -dSubsetFonts=true -dEmbedAllFonts=true -sPAPERSIZE=a4

Le gros probleme que je n'ai pas encore resolu, c'est comment changer automatiquement l'espace de couleurs des eps inclus dans le latex (ie une imprimerie souvent ça attend du CMYK alors que les eps sont souvent en RGB). Si vous avez des tuyaux, je prends...

Tout pareil : sur mon amd64 2.2GHz (un 3500+) une grosse compilation me semble plus rapide que sur le P4 2.4GHz du boulot, voire que sur un autre P4 2.8 GHz. C'est tres subjectif et je ne cause que de la compilation qui depend aussi d'autres facteurs (le disque, la memoire).

Sinon, pour les softs, quand ca coince en pur 64bits on peut toujours executer les applis 32bits qui vont bien. Les deux mondes cohabitent tres bien ensemble sans avoir a rebooter.

Oui. On encore, si c'est un simple truc graphique, il y a certainement une boucle d'evenements. Dans toutes les bibliotheques graphiques (... que je connais) il y a moyen de programmer un "timeout", ie de dire au bidule d'executer une routine regulierement quand il n'y a pas d'evenements GUI a traiter. Genre en gtk c'est gtk_timeout_add() de mémoire, en fltk c'est Fl::add_timeout, en Fox c'est FX::FXApp::addTimeout, en Qt c'est QTimer, etc. Bref, en général, pas besoin de threads.

Il y a pstruct pour ça. Et swig pour ce qui est des generateurs de wrappers.

man popen aussi, c'est encore plus pratique pour causer à gnuplot.

Il y a 2 ans ça marchait bien (Mac OS 10.2 je crois). cf :
http://david.decotigny.free.fr/libre/ibook2-debian/ibook2-de(...)

> Exit (pour un temps ?) les sections systèmes

Pour ce qui est des articles "conception d'OS" (ie "SOS"), c'est temporaire. Le prochain article est prevu pour Decembre prochain. Voir ce message pour les details :
http://the-doors.enix.org/pipermail/sos/2005-August/000486.html(...)

Pour ma part, j'utilise une bidouille "maison" : un script qui s'appelle "calepin.sh" et qui construit un fichier xml par mois contenant des entrées du genre :
-----------------------------------------------------------------------------------------
<day date="2005-04-05">
<entry time="17:57">
Blah blah il fait beau blah blah
Blah blah c'est la fete blah blah
</entry>
<entry time="23:59">
Blah blah demain est un autre jour blah blah
</entry>
</day>

<day date="2005-04-06">
....
-----------------------------------------------------------------------------------------

C'est très basique mais ca permet de garder une trace. Le script "calepin.sh" :
-----------------------------------------------------------------------------------------
#! /bin/sh

ENTRYEDIT=vi
[ x"$EDITOR" != x ] && ENTRYEDIT="$EDITOR"
[ x"$VISUAL" != x ] && ENTRYEDIT="$VISUAL"

CALEPIN=$HOME/perso/calepin-`date +"%Y-%m%B"`.xml
NOTE=/tmp/nototo-$USER-$$.txt
HEADDATE=`date +"%F"`

$ENTRYEDIT $NOTE
if [ ! -f $NOTE ] ; then
echo "Pas de message. Abandon."
exit 1
fi
if [ x"`wc -w $NOTE`" = x"0 $NOTE" ] ; then
echo "Pas de contenu. Abandon."
exit 1
fi
recode latin1..XML-standalone $NOTE

if [ -f $CALEPIN ] ; then
cp -f $CALEPIN ${CALEPIN}~
fi

HEADER="<day date=\"$HEADDATE\">"
if grep -q "$HEADER" $CALEPIN ; then
sed '$s%</day>$%%' < $CALEPIN > $CALEPIN.new
mv -f $CALEPIN.new $CALEPIN
else
echo >> $CALEPIN
echo $HEADER >> $CALEPIN
fi
echo " <entry time=\""`date +"%R"`"\">" >> $CALEPIN
cat $NOTE >> $CALEPIN
echo " </entry>" >> $CALEPIN
echo "</day>" >> $CALEPIN

rm -f $NOTE
echo -e "\e[34mCalepin mis a jour\e[m"
-----------------------------------------------------------------------------------------

Non, pas taper ! Désolé, j'ai fait l'impasse sur le 'M' dans 'bs=1M', je retire donc ce que j'ai dit sur la leeeenteur : c'est faux.

Le bs=1 est peut-etre un peu violent (lent).

Sinon, pour que le fichier ne prenne pas trop de place réelle sur le disque, le mieux est peut-etre un petit programme C qui fait juste un appel a ftruncate, ou d'utiliser qemu-img create. Sur les FS comme ext2/3, le fichier créé de cette manière ne prendra que quelques ko sur le disque tant qu'on n'essaiera pas d'ecrire dessus.

Essaye sans chrooter : option -r de Lilo.

D'un point de vue purement technique, je crois (je n'ai jamais testé, donc à confirmer) que tu peux utiliser libwine pour ça. Tes sources n'auraient alors pas a etre beaucoup modifiees. Mais, d'un point de vue elegance, il vaut mieux repenser le code pour se placer au-dessus d'une API plus portable et/ou plus "neutre" (wxwidget, fox, fltk, qt, etc.). On définira le terme "neutre" comme on le sentira... c'est toujours une affaire de gouts et d'habitudes apres tout.

> la database a été interdite par le PCI SIG il y a quelques années je crois

Faux : http://pciids.sourceforge.net/(...)

C'est le serveur qui envoie la duree de la concession au client. En general le client la respecte, c'est plus prudent (comme ça il est plus sûr de conserver son adresse IP). Si le client ne veut pas la respecter, il le peut. Je vois que le dhclient.conf propose une option supersede et une autre renew. Je ne sais pas laquelle fonctionne. Mais sans doute le plus propre serait de négocier cette durée de concession avec le serveur : l'option requested-lease-time.

J'imagine que la carte video est PCI ou AGP. Je ne prends pas beaucoup de risque en disant ça... ça fait bientôt 10 ans que c'est le standard.

Il suffira alors de faire : lspci et ça donne la liste des périphériques PCI (et AGP). La plupart devrait être reconnu par lspci. Si tel n'était pas le cas, ce qui est peu probable, il faudrait rechercher le PID/VID sur nain terre nette mais ça ne sera pas facile (la database a été interdite par le PCI SIG il y a quelques années je crois).