David Decotigny a écrit 103 commentaires

Ça doit dépendre des distros. Chez moi, /etc/modprobe.d ne liste pas les modules a charger bien que, je crois, ce soit chose possible... enfin, "de mon temps", ça l'était.

Je ne sais pas qui se charge de lancer le chargement des modules (udev sans doute chez moi), mais pour le guider, il y a la notion d'alias. Il y a donc ces aliases qui permettent d'automatiser les choses (voir ci-dessous) mais il reste possible de forcer un peu les choses à la main. Par exemple dans udev tu peux indiquer de charger des modules particuliers, exécuter un script (par exemple pour charger un firmware), etc. quand un événement particulier se produit (eg. apparition d'un nouveau matériel). J'imagine que l'outil de chargement en question dépend des distros.

Un alias peut être un block/char major/minor par exemple. Ou un pciid, usb id, etc. Pour définir ces aliases, ça peut se passer à la main dans /etc/modprobe.d. Par exemple :

  alias char-major-M-m mon_module
  (et autres: man modprobe.conf)

En règle générale, pour le matos, ça se passe plutôt automatiquement grâce aux infos stockées dans les .ko. Par exemple :

  shell# modinfo /lib/modules/mon_noyau/kernel/drivers/net/bnx2x.ko
  [...]
  alias:          pci:v000014E4d00001650sv*sd*bc*sc*i*
  alias:          pci:v000014E4d0000164Fsv*sd*bc*sc*i*
  alias:          pci:v000014E4d0000164Esv*sd*bc*sc*i*
  [...]

Ces informations sont actualisées par depmod qui les scanne tous et stocke le résultat dans /lib/modules/mon_noyau/modules.alias et autres fichiers dans le même répertoire. La chose qui s'occupe de récupérer le matos / détecter le nouveau matos doit utiliser ça pour savoir quel(s) module(s) charger (eh oui, depmod s'occupe aussi de déterminer les "dépendances" entre modules, dans modules.dep, que des outils comme modprobe savent exploiter pour simplifier leur chargement/déchargement).

Pour faire le lien entre le matos et ces alias, il y a des messages noyau envoyés par les drivers de bus quand un matos est détecté (google uevent), et que des outils comme udev savent récupérer. Et quand sysfs est dispo, il y a des attributs sysfs qui peuvent aider a posteriori (sinon, lspci, lsusb, rulez), genre:

  shell# cat /sys/devices/pci0000:00/0000:00:03.0/0000:02:00.0/modalias
  pci:v000010DEd00000659sv000010DEsd0000063Abc03sc00i00

Pour la petite histoire, c'est la macro MODULE_DEVICE_TABLE() qui permet de définir la liste des aliases intégrée dans un fichier .ko.

La réponse est un peu partout dans le noyau, ou là : http://lwn.net/Kernel/LDD3/ ou encore là : http://sos.enix.org/ ... Il y a ce qu'on appelle des primitives de synchronisation dans un noyau (genre mutex, sémaphore, waitqueue, conditions parmi bien d'autres). Ces primitives peuvent permettre par exemple (au hasard) à une interruption de réveiller un thread en attente. Utiliser uniquement des spinlocks n'est pas la bonne solution (ne fait rien en UP, monopolise un CPU en multipro) : elle sera peut-être nécessaire mais certainement pas suffisante.

J'ai un e6400 depuis janvier (core 2 duo). Je ne connais pas vraiment les différences avec le 6500, mais le mien marche très bien : mise en veille, wifi, 3d, webcam, écran externe (dvi sur le dock, ou vga du laptop), ... Aucune mauvaise surprise. Note que j'ai une Nvidia, pas une intel. La seule chose non testée : bluetooth.

Ça tourne sous intrepid de base sans customisation de fou. Sous jaunty il devrait aussi marcher, bien que sur le mien, je doive sûrement utiliser une vieille version du driver nvidia (mais j'imagine que tu n'es pas concerné).

Ils utilisent d-i, euh... "ubiquity" : https://wiki.ubuntu.com/Ubiquity

En passant, au moins un bug rencontré hier avec l'ubiquity de Jaunty : ils essayent de migrer vos anciens home des autres partitions vers la nouvelle installation... et ça explose si la nouvelle partition est trop petite. Utiliser l'option --no-migration-assistant pour contourner le problème.

Ces liens et tes réponses semblent indiquer que c'est pas mal fait à la mano, tout ça. J'imagine que, dans ces conditions, chaque développeur ubuntu a pondu et utilise sa propre version d'un truc comme https://linuxfr.org/~11010010/28314.html .

J'ai cru comprendre que fakeroot était surtout un LD_PRELOAD. J'imagine que ça permet de faire croire à des trucs comme ar ou tar que les fichiers créés par un utilisateur non root appartiennent en fait à root, etc.
Mais je doute que ces LD_PRELOAD aillent jusqu'à simuler un mount, un chroot, ou un su (pour passer root dans le chroot). M'enfin, si vous avez plus d'infos...

Voui, c'est pas faux, ça pourrait aussi marcher avec kvm. Mais chez moi, kvm se transforme en qemu (mon CPU est trop vieux pour supporter les extensions de virtualisation), qui est moins rapide que VirtualBox (un mystère pour moi, d'ailleurs) et/ou qui bloque au démarrage de l'image.

Voui, mais quand j'avais essayé, ça marchait pas (tm).
M'enfin là, je viens de re-tenter le coup, et avec un peu de google, ça donne ça : http://david.decotigny.fr/wiki/wakka.php?wiki=LiveHelperUbun(...)
Bref, sur un jaunty avec un peu de magie, ça marche, en effet.

Merci d'avoir re-titillé mon neurone là-dessus !

Oui, c'est aussi une solution. Assez déclarative, mais pourquoi pas.

Ce que je verrais bien, c'est qu'après avoir décrit la structure de tes données sous la forme d'objets "champs" comme tu présentes, tu utilises cette description pour générer le code C++ "optimisé" qui définit de nouvelles classes coquilles (genre beans avec get_/set_ sur chacun des champs que tu as décrits). Ensuite tu utilises ces objets coquille pour travailler avec tes données brutes.

C'est un peu cette dernière approche "génération de code légère" que je recherche et je me demandais surtout si qqch comme cela existait déjà et était répandu.

Merci, c'est intéressant. Par contre j'ai l'impression que ça ne gère pas les bitfields "en standard". Il faut sans doute passer par la définition de classes supplémentaires. C'est probablement une proposition qu'il serait intéressant de soumettre aux auteurs de ce package. Mais intéressant quand même.

En effet. C'est __attribute__ ((packed)) et autres __attribute__ ((aligned(X)))... qu'on est bien obligés d'utiliser pour ce genre de choses.

Je ne suis pas convaincu que ce soit une tare du C (enfin : de gcc en l'espèce) que de réarranger la structure effective et l'alignement des choses en mémoire afin d'"optimiser" ou tout simplement afin de s'adapter aux contraintes d'alignement des CPU.

Après tout, la notion de structure est davantage sémantique dans un langage "de haut niveau", que véritablement physique. Parlez-en à un électronicien, pour lui le C est bien un langage de haut niveau ;)

C'est en effet une solution sur laquelle je pensais partir. Mais je préfère devoir faire les ntoh*/hton* à chaque accès à un champ (ça se traduit par un opcode [bswap] sur x86) que d'avoir à dupliquer chaque paquet pour le ntoh*-er.

Ici on utilise rlwrap.
Tiens, je vois ça : http://kb.dbatoolz.com/tp/642.sqlplus_-__rlwrap__readline_wr(...)

Youpi, c'est pas mal ça ! Merci ! Connaissez-vous d'autres offres du même style ?

Merci. Bien sur je pense a spip. connaissez-vous des choses equivalentes, un peu moins complexes ? Le concept de pages suffirait, pas besoin de tout le bazar articles, breves, etc.

Au choix:
- lancer "xscreensaver-demo", répondre "No" quand il demande si "il faut lancer le screensaver daemon now ?". Dans onglet "Advanced", Cocher (au moins) "choose random images", puis sélectionner le répertoire où il y a les images.
- OU éditer/créer ~/.xscreensaver:
chooseRandomImages: True
imageDirectory: /répertoire/vers/les/images

Ensuite faire:
shell> killall gnome-screensaver
shell> gnome-screensaver

C'est un réglage par utilisateur et apparemment ça descend dans les sous-répertoires.

Tout cela m'a l'air bien flou. Si j'ai bien compris, il y a 2 problèmes :
- attente d'évènements venant de 2 sources différentes (tty et ttyS)
- pour tty, attente en mode "caractère" plutôt que "ligne"
Dans les 2 cas, inutile de s'intéresser aux IRQ : c'est le noyau qui gère ça. Les gérer soi-même signifierait... modifier le noyau. Ce serait ridicule parce que tout ça est possible en espace user, et il y a même moyen de faire quelque chose de portable (solaris, *bsd, ... mac os ???).

Pour le premier point, select ou poll sont des solutions (RTFM).
Pour le deuxième point, info libc, rechercher "non canonical input" (ou http://info2html.sourceforge.net/cgi-bin/info2html-demo/info(...) ). Pour ce qui est du cas spécial du "Ctrl-C", man signal : c'est SIGINT qu'il faut rattraper.

Evidemment, tout ca est accessible directement par la libc. Mais j'imagine qu'en utilisant des bibliotheques de plus haut niveau (glib, *curses, slang, etc.) il y a moyen de se simplifier la vie.

Pendant que ça cause Linux sur Mactel, est-ce que quelqu'un peut me dire si un Linux 64bits fonctionne sur les dernières versions des 2 familles de portables (Macbook/Macbook pro ont du core 2 duo désormais) ?

Une solution :

xprop -f _MOTIF_WM_HINTS 32c -set _MOTIF_WM_HINTS "0x2"

Bon, voilà voilà je suis content... mais je vais garder devilspie ;) Pendant que j'y suis, pour rendre la fenêtre transparente (pas possible avec devilspie... mais je crois que je vais me faire un petit patch pour appeler xprop depuis devilspie) :

xprop -frame -f _NET_WM_WINDOW_OPACITY 32c -set _NET_WM_WINDOW_OPACITY 0x80000000

... dans ce cas il faut que l'extension Composite soit activée. On peut utiliser aussi transset pour ça, mais l'inconvénient est qu'on ne peut pas scripter. Merci à http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency !

Il semblerait que metacity ne tienne pas compte de la ressource-qui-va-bien (???) :

Mwm*XConsole.clientDecoration: none

Bon, devilspie fait le boulot, j'ai juste peur qu'il fasse des choses bizarres dans mon dos. Donc si vous connaissez des petits utilitaires en ligne de commande qui modifient _MOTIF_WM_HINTS, ça m'intéresse. J'ai essayé avec xprop mais sans succès.

Ah enfin un machin pas cliquodorme ! Gé-nial :

(if (is (application_name) "xconsole")
    (begin
       (undecorate)
       (geometry "483x116+949+26")
    )
)

Merci ! Bon, j'ai quand même quelques craintes :

** (devilspie:29118): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL' failed

Et puis je me dis que ça doit être possible de rajouter ce qu'il faut dans le .Xresources, mais je sais pas quoi (c'est pour une xconsole or donc).

Un autre cliquodrome : wifi-radar http://wifi-radar.systemimager.org/

Je ne comprends pas trop ton problème. Bon, c'est sur, le memcpy avec gcc se compile plutot bien, mais une solution plus directe serait :

  DWORD * ptr = alloc.addrStart;
  *ptr = 0xdeadbeef;

Ou encore, en moins lisible :

   * (DWORD*)(alloc.addrStart) = 0xdeadbeef;

Ca genere le meme code que memcpy. Par exemple, si je compile avec gcc -O -fomit-frame-pointer, alors objdump -M intel -S me dit :

 8048330:       a1 64 95 04 08          mov    eax,ds:0x8049564
 8048335:       c7 00 ef be ad de       mov    DWORD PTR [eax],0xdeadbeef

Si tu veux que ton driver permette les read, il faut implementer le read, si tu veux qu'il fasses les writes, il faut implementer le write, pour les ioctl c'est ioctl, etc... Donc pour select/poll meme combat : ton driver doit faire le necessaire. Sinon tu ne recupereras que le comportement par defaut de l'OS, qui ne fera pas grand chose de magique.

Voir par exemple http://lwn.net/Kernel/LDD2/ch05.lwn#t3 et http://lwn.net/images/pdf/LDD3/ch06.pdf

En effet. A ma connaissance ce n'est pas possible sur une console standard, a part peut-etre avec les touches speciales qui permettent les combinaisons de touches (genre Esc-..., Ctrl-... ; je ne sais pas comment ca marche dans ce cas mais a mon avis tu ne recuperes que la combinaison, pas les evenements appui/relache).

Par contre c'est possible sur la console linux, voir showkey et drivers/char/vt_ioctl.c du noyau.