007 a écrit 2187 commentaires

> Dès que nécessaire... OK mais quand et par quel script ?

Pour le propriétaire de /dev/snd/* c'est fait pas pam. Celui qui obtient la console est le propriétaire des fichiers.
Exemple :
- boot
- login toto => /dev/snd/* apartient à toto
- login titi => /dev/snd/* reste toujours à toto
- déconnexion de titi et toto
- login titi => /dev/snd/* apartient à titi

Les modules peuvent être chargés à la demande. Ça ne marche pas pour tout. Par exemple, si tu accèdes à /dev/hdc qui est un lecteur de CDROM, le drivers de CDROM est chargé.
De même, si tu accèdes par exemple à /dev/snd/pcmC0D0p les modules pour le son sont chargés. Bref, pas de script (du moins pour le son). A ma connaissance, le seul fichier qui charge des modules est /etc/rc.d/rc.sysinit .

Ceci dit, je crois qu'il ne faut plus se prendre la tête avec ça. Avec udev (et déjà avec usb/pcmcia), ce modèle ne marchera plus (ou pas très bien) et tous les modules seront chargés par un script (détection du matériel puis chargement des modèles dès le boot même si les périphériques ne sont pas utilisé).

> Bref sizeof (void *) == sizeof (char *) >= sizeof (autre_chose *)

Tu as raison (pas seulement au niveau norme).
D'un point vu implémentation à cause (ou grace) à l'alignement c'est assez logique pour les petits systèmes (ou très spécialisés).

Mais compte-tenu de ça (sizeof (char|void *) >= sizeof (autre_chose *)), il peu y avoir perte d'information lors d'un (autre_chose *) = (char *). Reste aussi les problèmes d'alignement "classiques" que j'ai déjà rencontré. Je devais récupérer un fichier binaire sur Dec/Alpha et j'ai bien galéré avec l'alignement (alignement de 4 pour les long et alignement de 8 pour les struct (pointeur) contre 2 et 4 pour le système d'origine (Vax)).

> Quand je disais "mettre à jour" j'entendais appliquer les updates.

Désolé.

> Sinon, ça ne résouds pas mes pbms de modules :'( !

J'ai pas de solution mais la suite va peut-être aider.

C'est maintenant Linux 2.6 et la gestion des modules a changée. Tu l'as sûrement remarqué.
Sous FC2, les valeurs par défaut pour modprobe sont dans :
/etc/modprobe.conf.dist

Normalement il ne faut pas y toucher.

> une AWE64 ISA

Les cartes ISA ne sont pas supportées depuis Fedora Core 2 (le programme dédié au son est 'system-config-sound'). Par contre, les modules sont toujours compilés.

> Dans mon /etc/modprobe.conf

Voilà mon modprobe.conf :
alias snd-card-0 snd-ens1371
install snd-ens1371 /sbin/modprobe --ignore-install snd-ens1371 && /usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-ens1371 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-ens1371

Notes que je n'ai pas 'install snd-card-0 ...' mais 'install snd-ens1371 ...'

Fais un essai sans utiliser l'alias snd-card-0 . Je ne sais pas si ça va marcher mais ça ne peut pas faire de mal.

> # OSS Emulation
> alias sound-slot-0 snd-sbawe

Normalement tout est en place dans /etc/modprobe.conf.dist

> Ensuite, j'ai ajouté dans mon /etc/rc.local la ligne suivante (si vous connaissez d'autres méthodes, je suis preneur):
> # SB AWE64
> /sbin/modprobe snd-card-0

Je n'ai pas ça. Chez moi snd-card-0 est chargé dès que nécessaire. Par contre, vérifies si tu as les droits sur /dev/snd/* . Celui qui a la console (voir /etc/security/console.perms) est propriétaire de ces fichiers. Mais il n'y a qu'un id à la foi qui peut accéder à ces fichiers.


Pour lm_sensors, j'y connais rien :-)

Ça ressemble plus à un problème de routage ou firewall que de résolution de nom.

Tout marche avec rpm :
[test@ici test]$ rpm -q test
test-1+2-1
[test@ici test]$ rpm -q test-1+2
test-1+2-1
[test@ici test]$ rpm -q test-1+2-1
test-1+2-1

"yum remove test-1+2" ou "yum remove test-1+2-1" ne marche pas. "yum remove test" marche.
Idem pour "yum info".

Tu peux créer un bugzilla pour FC2 (composant yum).
Mais c'est peut-être un bug rpm-python. J'en ai vu un passer récemment sur la mailing devel (spécifique avec python 2.3.3 (FC2) alors que ça marche avec python 2.3.4).

Idéalement il faudrait mettre à jour vers rawhide.
Tu trouveras des gens avec des machines en rawhide sur la mailing test. Ce n'est pas mon cas actuellement.

Si tu ne reproduit pas ce "petit" bug avec rawhide (ou FC3T1), il est possible qu'il soit ignoré.

> j'ai installé apt4rpm pour pouvoir mettre tout à jour.

apt ou yum ou (n'importe quoi d'autre basé sur rpm) n'est pas prévu pour les mises à jours d'une release à une autre. Ce n'est pas un problème rpm, c'est simplement car les paquets ne sont pas fait pour ça.

Par contre anaconda doit le faire (installation depuis les CD-ROM puis demander "mise à jour").

Donc si ça ne marche pas, c'est presque normal.

> c'est parce que tous les pointeurs vers des struct ont la même taille

struct titi {
int entier ;
} ;
Et voilà, j'ai une structure qui fait la taille d'un int qui s'utilise comme un int, etc...
De plus la norme (oui oui), autorise :
(n_importe_quoi *) = (void *)
et
(void *) = (n_importe_quoi *)

n_importe_quoi peut-être un char.
Donc je me demande comme un (void *) peut ne pas voir la taille d'un (char *) alors qu'il peut stocker un (char *) et vice versa.
btw, un malloc retourne toujours un (void *) et malloc peut-être utilisé pour tous les pointeurs (même (char *)).
Merci de me trouver la réponse...

Remplace MDI par KDE.

KDE avait plein de bonnes idees, dont un certain nombre ont abouti a qqch de pas trop mal.

T'es d'un trollesque toi ...

J'aimerai bien faire des choses de "pas trop mal" comme lui.

> http://www.vmunix.com/~gabor/c/draft.html(...)

Merci, je bookmark :-)

> sizeof(toto *) != sizeof (void *)

Non. sizeof(int*), sizeof(toto*), sizeof(n_importe_quoi *) est égale à sizeof(void *).

C'est pour celà que des trucs tordus comme ci-dessous sont possibles :
typedef struct list * plist ;
static size_t taille = sizeof (struct list *) ;
static size_t taille2 = sizeof (struct list) ; // invalide => invalid application of `sizeof' to an incomplete type
static size_t taille3 = sizeof (plist) ;
struct list {
     struct list * prec ;
     struct list * next ;
     data ;
} ; // la taille de "struct list" n'est connu que ici.
static size_t taille4 = sizeof (struct list) ; // valide => le taille est maintenant connue.

Ceci marche car "struct list *" est connu en taille avant même sa déclaration et la taille est sizeof (void *) (ou (n_importe_quoi *)).

par contre sur certains plate forme (64 bits notament) sizeof(0) != sizeof(void *).

> > static char* p ;
> p est un null pointer

Non, c'est initialisé à 0. C'est le chargeur qui fait ça. C'est peut-être pas dans la norme mais c'est comme ça. Le chargeur ne s'occupe pas de savoir si c'est une zone qui stocke des pointeurs ou des int, etc... Le chargeur voit une grosse zone (pour toutes les variables statiques) et met tout à 0.

Si tu as la norme sous main, copie ici comment est initialisé une zone static (C'est aussi pour mon information car je n'ai pas la norme, btw, si tu as un pointeur sur la norme, je suis preneur).

> > void * p = (void *)(p1 - p2) ;
> 0 pour p

Pourtant tu dis : '0' même signification que '(void *)0' même signification que null pointeur. Or ici j'ai bien '(void *)0' (c-à-d null pointeur) et tu dis que c'est 0. Pas claire.

> ça n'a pas de sens, NULL est une macro

Remplace NULL par "null pointer" si tu veux.

> 100%
Non. pour varargs, ça ne marche pas.
Heureusement, gcc a la délicatesse de le dire :
printf("%p\n", 0) ;
test.c:3: attention : l'argument de format n'est pas un pointeur (arg 2)
avec :
fprintf("%p\n", NULL) ;
Pas de warning, c'est correct.

Avec c++ ça ne marche pas avec la surcharge. 0 reste un int. (void*)0 est un pointeur et NULL est null pointeur (implémentation dépendant de la plate forme).

Exemple :
test.c
#include <stdio.h>
void f(int i) {
    printf("f(int)\n") ;
}
void f(void *s) {
     printf("f(void *)\n") ;
}
void f(char *s) {
     printf("f(char *)\n") ;
}
void f(long u) {
     printf("f(long)\n") ;
}
int main(void) {
     f(0) ;
     f((void*)0) ;
     f((char*)0) ;
     f(0L) ;
     f(NULL) ;
     return 0 ;
}


g++ -Wall test.c
test.c: Dans function « int main() »:
test.c:15: attention : passing NULL used for non-pointer converting 1 of `void f(int)'

NULL est remplacé par __null qui est un mot clé de g++.
Mais d'autres implémentations ont un truc du style :
# ifdef __cplusplus
#     define NULL (0L)
# else
#     define NULL ((void*) 0)
# endif


Exécution :
./a.out
f(int)
f(void *)
f(char *)
f(long)
f(int)


Donc ce n'est pas la même chose et surtout pas à 100 %.

> Ils ne font pas confiance aux équipes de développement qui produisent lesdits logiciels quand ils sortent une nouvelle version stable ? Ce n'est pas une raison suffisante pour les proposer en mise à jour ? Quelles autres raisons ? Je n'en vois pas.

Peut-être par manque de temps/argent ?
Faut faire le paquet, compiler, tester un minimum (problème de compatibilité), mettre sur les mirroirs, etc...

A celà s'ajoute tous les problèmes de dépendance... (les logiciels évoluent et leurs dépendances aussi), le problème d'audit du code, etc...
Bref, la complexité augmente en flèche.

Pour Fedora, il faut un mois de freeze complet (pas de changement de version et que des corrections de bugs) pour fiabiliser alors que les développeurs ne s'occupent que de ça. Pourtant il reste encore des problèmes lors de la release finale...

Monter en version un paquet se fait parfois sans accro. Ce n'est pas toujours le cas.

L'article (et pas la news cette fois) est intéressant mais il loupe un gros truc :
- les objectifs

RHEL ne va pas sortir tout les 6 mois car l'objectif est d'avoir un système perenne (5 ans). Si il y a une nouvelle version tout les 6 mois, celà fait jusqu'à 10 versions à maintenir en même temps !
Fedora dont la perennité est courte peut sortir plus souvent. Parlé de la fréquence de sortie sans prendre en compte les objectifs n'est pas "très sérieux".

Puis les distributions c'est particulier. C'est pas vraiment lié à son développement mais au développement de tous les autres. Si la distribution ne bouge pratiquement pas mais qu'il y a une nouvelle version de Gnome ou KDE, alors il y aura une nouvelle version de la distribution.

> Les deux « pointures » commerciales que sont Suse et RedHat ne bénéficient pas d'une large communauté de contributeurs
> actuellement il semble toutefois que la grande majorité du travail reste effectué par les développeurs RedHat

Mouaifffff
Ce n'est pas tout à fait faux.
Mais ce n'est pas tout à fait vrai.
Je ne parle pas de SuSE que je connais peu.

Prenons Fedora. Pour la prochaine FC3, udev n'était pas vraiment prévu car il y avait des problèmes génants selon Red Hat (côté mkinitrd notament). Des développeurs d'udev sont passés sur la mailing devel de Fedora pour fixer les problèmes et il est maintenant plus que probable que udev sera par défaut dans FC3.

FC2 poussait SeLinux, et quelques développeurs de SeLinux ont aussi participés à FC2.

Fedora n'est pas communautaire (comme Debian) et moins ouverte que Mandrake par exemple (ça devrait changer avec un nouvelle système de build qui ... sait se faire désiré :-)).
Mais les développeurs de Red Hat sont si impliqués en upstream qu'il y a forcément une grosse communauté derrière mais si c'est "à distance".

L'un des objectifs de Fedora est d'être synchro avec l'upstream :
http://fedora.redhat.com/about/objectives.html(...)
Do as much of the development work as possible directly in the upstream packages.

Ainsi des gros projets comme le noyau, gcc, binutils, gnome etc peuvent sortir avec la dernière version disponible et très peu de patch grace à la participation en uptream (et à distance par rapport à la distribution).

Mon argumentaire n'est pas très brillant, mais Fedora a une grosse communauté. Pas forcément très nombreuse ou qui intervient directement. Mais techniquement de haute volée.

Il serait bien d'avoir un sondage sur les distributions utilisées par les développeurs en upstream. Je ne serais vraiment pas étonné que Fedora soit en tête même si les développeurs ne participent pas directement au développement de la distribution.

Ceci dit, il y a aussi fedora.us pour les contributions externes :
http://www.fedora.us/(...)

Et pour mettre un bénol à tout ça, les outils de configuration, les scripts de boot, l'installeur, etc (ce qui est vraiment du domaine de la distribution) reste à 90 % dans les mains d'employés Red Hat.
Donc je te donne raison pour la partie distribution. Mais une distribution comme Fedora n'a pas comme objectif d'uniquement paufiner les outils de configuration, l'installateur, etc... Ç'est 5 à 10 % du boulot de Red Hat/Fedora alors que leur métier est de faire une distribution.

> Non, on peut pas.

Non, on peut pas :-)
J'ai mélangé les pinceaux.

> C'est deux instructions sont complètement équivalentes et ont exactement la même sémantique (pour peu que p soit un pointeur, hein).

Oui c'est complètement équivalent et a la même sémantique.
Si on se "limite" à ça, c'est complètement inutile utiliser NULL au lieu de 0 (3 caractères de plus sans aucune valeur ajoutée).
Je parle de signification.

Puisque 0 est équivalent à null pointer (car le compilo fait une "bidouille") que ce passe-t'il dans ces cas :
static int i ; // équivalent à static int i = 0
static char* p ;
static char *p[10] ; // tableau de pointeur à 0 (bit à 0) ou null pointeur ?
static union {
long i[10] ;
void * p[10] ;
} titi ;

Tous les pointeurs sont initialisés à 0 (bits à 0) ou à null pointeur (qui n'est pas forcément 0) ?

char * p1 = "toto" ;
char * p2 = p1 ;
void * p = (void *)(p1 - p2) ;
C'est équivalent à "(void *)0" . Mais 0 ou null pointer pour p ?
Normalement c'est 0 et pas null pointer. La soustraction de deux trucs valide ne donne jamais NULL. Ici la réponde est 0 et pas null pointeur mais si c'est la même chose qui est stocké sur certaine implémentation.

Dans 99,9 % des cas, on peut remplacer NULL par 0, mais ça n'a pas la même signification.

> Pas du C, on ne peut pas additionner deux pointeurs.

Oui on peut (même si généralement c'est une très mauvaise idée). Il faut qu'il soit du même type et pas du type void* .

> > Ça n'a pas la même signification qu'avec les autres types.
> Si c'est pareil, on compare p avec 0

J'ai dis "signification".

Sur l'aspect signification, ce n'est pas la même chose.
p = 0 // adresse 0
p = NULL // adresse invalide ou non renseigné, etc

Si à NULL tu lui donne la signification de '0', effectivement c'est la même c'est la même signification :-).
Mais la "notation" NULL est bien là pour différencier de '0'.
'0' indique 'rien'. Pas de patates cette semaine, 0 Francs de solde sur le compte. Mais NULL en solde sur le compte j'ai pas encore vu ça :-) Ou alors on veux indisquer que le compte est NULL (invalide ou n'existe pas). Dans ce cas c'est compte = NULL et non pas solde = NULL.

Beaucoup de language font la distinction entre NULL et 0. Par exemple SQL (limite casse couille leur convention) et php (qui ajoute aussi la distinction set/unset puisque qu'il n'y a pas de déclaration de variable).
Avec php (j'ai un peu oublié la syntax) :
isnull(toto) => false ; toto n'est pas défini
toto = NULL
if (toto) => erreur/warning, on ne peut pas évaluer
toto == 0 => false ; toto est à NULL et pas à '0'
toto = 0
isnull(toto) => false ; toto n'est pas NULL, mais à '0'

Le C est un peu particulier. Il n'y a que les adresses qui peuvent être NULL (toujours sur l'aspect signification) et tu peux aussi utiliser l'adresse 0 (pour faire un reset ou d'autre truc de très bas niveau). Il n'y a pas de int/float/etc NULL. Ceci pour des raisons de performances sinon il faut vérifier à l'exécution. Un int/float/etc a toujours une valeur valide (sauf pour float avec certain librairie de calcul si on chipote).

Je ne dis pas que tu as tord sur la norme (de tout manière, j'ai pas la norme sous la main...). Je dis simplement que je n'ai jamais vu d'implémentation qui traite de façon particulière un null pointer. C'est tout.

> notamment le résultat des comparaisons et conversions de null pointer entre eux ou avec des pointeurs valides.

Si c'est dans l'esprit SQL :
char * f (char *p, char * t) {
return (p + t) -t ;
}
si f(NULL, "titi") alors NULL doit être retourné.

Ceci demande des vérifications à l'exécution et ce'est pas dans l'esprit du language C.

Ceci dit, un "#define NULL ((void *)xx)" sans traitement particulier du compilateur me convient parfaitement.
De plus je ne fais jamais de "if (p)", "if (!p)" ou "if (p=malloc(2)) je fais toujours "if (p != NULL)", "if (p == NULL)" et "if ((p = malloc(2)) != NULL).
Notes que je ne suis pas le seul à faire comme ça (je ne parle pas de Linux).

D'usage rare, la macro isnull est sympa :
#define isnull(p) \
((p) == NULL)

If faut toujours utiliser NULL et ne pas considérer que NULL est égale 0. Comme ça il y a pas de problème.

Je pense que les compilateurs devraient mettre un warning pour les "if (p)", "if (!p)". Ça n'a pas la même signification qu'avec les autres types.

> f(a)

surtout avec la surcharge en C++ . S'il y a f(int) et f(void*) :
f(0) et f(NULL) n'appelle pas la même fonction.

Donc (0 != NULL) même en C++.

> c'est bien le compilateur (ou le front-end, en tout cas c'est pas la lib) qui a la charge de convertir ce 'null pointer constant' en 'null pointer'.

Mouaif...
J'ai beaucoup codé en C (plus actuellement mais je vais m'y remettre) et j'ai jamais vu un compilateur traiter différement NULL ou "(void*)0" ou "(void*)1" ou "(void*)29898".

Exemple :
tmp1.c :
#include <stdio.h>
int main(void) {
char *p = NULL ;
printf("%c\n", *p) ;
return 0 ;
}

tmp2.c :
#include <stdio.h>
int main(void) {
char *p = (char *)2 ;
printf("%c\n", *p) ;
return 0 ;
}

gcc -o tmp1 tmp1.c
gcc -o tmp2 tmp2.c
cmp -l tmp1 tmp2
900 0 2

Aucun traitement particulier n'est fait pour NULL et ça "Segmentation fault" de la même façon (normal).
Tu peux essayer d'autres exemples, NULL ou (void *)0 ou 0 est traité comme un pointeur "normal".

Ouais.

> le compilateur utilise la valeur 'null pointer'

C'est pas vraiment lié au compilateur. C'est la librairie C qui """gère""" ça.
Si tu ne fais pas "#include <stdlib.h>", tu as une erreur de compilation :
NULL : symbol non défini.

> Bah en C++ je crois que la norme précise que 0 == NULL

Tu me la trouve la norme qui dit ça ?
NULL conserne la librairie standard C (stdio.h stdlib.h, etc...). Le compilateur ne traite pas de façon spécial NULL (qui est généralement une macro vers "((void*)0)" mais c'est un "détail" d'implémentation qui doit être ignoré).
NULL n'est pas un mot clé du C ou du C++.

> c'était même un programme séparé

C'est toujours un programme séparé.
Fais "cpp --help"

btw, cpp ne connais presque rien du C ou C++. C'est aussi un très bon outil à usage général.

Pour le compilateur, l'adresse 0 (ou "(void *)0") est une adresse comme une autre.
Si tu veux exécuter une fonction à cette adresse, le compilateur n'aura rien à dire.
Si tu veux déférencer un pointeur pour lire ce qu'il y a à l'adresse 0, le compilateur te laisse totalement libre de le faire aussi.

Par contre le noyau fera planter le programme vite fait. Mais pas le compilateur.

btw, la norme du C ne dis pas que 0 ou "(void *)0" est un pointeur invalide. La norme C ("#include <stdlib.h>") dit uniquement que NULL est un pointeur invalide et cette norme ne donne pas la valeur de NULL (ce qui est normal puisque c'est invalide).

A lire le reste et pour résumer on peut dire que arch ne fait rien comme Linux.

http://lwn.net/Articles/93580/(...)

Y a pas à dire, j'adore Linus. Son "coding style" c'est le mien depuis des lustres.

C'est quoi splash.lss ?

VIVE MDI (qui fait la pluis et le beau temps) !!!

PS : tu disais ?

> en C++ il est préférable d'utiliser le '0'.

C'est pas ce que dit Stroustrup.

Il dit :
- "un contrôle de type plus sérieux rend moins problématique l'utilisation du 0 normal"

C'est différent.

Puis ça reste un problème :
- "Le nombre de problèmes est ainsi considérablement réduit."

Il est réduit, il n'est pas supprimé. Donc même en C++ il faut utiliser NULL.