et les 32 bits

• [^]Re: et les 32 bits

  Posté par demik () le 19/10/2007 à 13:35. (lien). Évalué à 10.

  C'est malheureux, mais je vais te rassurer un peu. C'est a peu près inutilisable sur 64 bits également.
  
  Nous sommes trois a avoir réalisé ce patch, le jour de la sortie, et on est arrivés à la même conclusion : le pilote est vraiment mauvais.
  
  En pratique, si j'arrive a charger les modules, il se passe l'une des étapes si dessous (c'est une vraie roulette russe).
  - plein de symboles indéfinis, il faut charger les modules dans un certain ordre, mais même avec le bon ordre, parfois ça pète (erreur au chargement, si on décharge ça KP)
  - un beau kernel panic
  - la machine freeze
  - ça passe
  
  Le coté amusant, c'est que d'un reboot sur l'autre, on a pas le même comportement.
  
  si ça se charge :
  - le son via alsa est craqué comme un vieux vinyle sale
  - le son "boucle" un certain temps quand on l'arrête
  - pas de SPDIF, pas de gestion des entrées auxiliaires (rack 5"1/4 en façade ou module externe)
  - son 2.0 maximum (pas de 4.0 / 5.1 / 7.1 etc...)
  - pas de 24 bits crystaliser, pas de CMMS-3D, pas d'EAX, pas d'accélération matérielle.
  - le son via l'émulation OSS est correct, minus le bouclage comme indiquer ci dessus
  - certains mixers ne marchent pas (je pense au graves / aigus, etc...)
  
  en gros on se retrouve avec une SoundBlaster 16 ISA, et avec un son plus sale.
  
  Bon après je suis assez mauvais en développement kernel, mais le code des pilotes est comment dire... mauvais. quelques extraits de tête des problèmes du pilote, j'en passe, et sûrement pas des meilleures. Si vous avez 15 minutes a perdre, chargez le pilote et regardez dedans, ça vaut le détour.
  
  - le tar a ses fichiers datés de 2009
  - l'installateur ne peut même pas se lancer sur aucune architecture, il ne fait même pas un uname correctement
  - le tar contient un autre tar, qui ne possède pas les bons droits (ex, scripts shells et dossiers sans +x, configure en 234, etc...)
  - le pilote n'as pas été compilé au delà du 2.6.15, et personne n'a bossé dessus depuis mai / juin (d'après ce que j'ai compris des sources)
  - ils utilisent des types deprected du noyau (c'est marqué en gros en haut dans les .h)
  - il manque a certains fichiers jusqu'à 4 includes pour compiler
  - certains pointeurs mémoires sont castés dans des int ou équivalents
  - #if 0, #define truc \n #ifdef truc, etc, typique d'un code alpha
  - une grosse partie du code est du copié / collé des sources du pilote windows (il y a des références a des cartes audigy, des sound blaster live, des structures et des types windows redéfinis, etc).
  - si je comprends bien le code, le driver était a la base un pilote oss, puis une sorte de wraper alsa a été rajouté par dessus.
  - il y a des outils redhat (chkconfig) en dur dans les scripts d'installation et de configuration.
  
  pour celle là j'ai un doute :
  - Le pilote semble utiliser des sous fonctions de l'allocateur mémoire (SLAB), c'est pour ça qu'il ne peut fonctionner pas avec un SLUB. (un module a le droit de faire ça ?)
  
  Bref, tu vois, distribution 32 bits ou pas, cela ne change pas grand chose. Le bon côté de ces pilotes, c'est qu'au moins, maintenant les gens du projet alsa ont quelque chose a regarder pour fournir un pilote de base (enfin je l'espère)
  
  Je termine avec une citation d'Oliver McFadden (un bon programmeur qui fait du reverse sur les cartes ATI) : "I was expecting a relatively small kernel module, not a bloated userspace driver." (source : http://olivermcfadden.livejournal.com/9984.html)

  • [^]Re: et les 32 bits

    Posté par √λιi () le 23/10/2007 à 08:51. (lien). Évalué à 2.

    (un module a le droit de faire ça ?)
    
    Un module a le droit de tout faire, il tourne en mode kernel, non ? La seule limite que je peux imaginer c'est pour le passage dans les 'ring' d'exécution (ring0, ring1, etc) qui permet d'avoir encore plus de contrôle sur le matériel, mais je doute qu'il y ai un moyen de limiter les agissements d'un module, y compris ceci.
    
    D'ailleurs c'est la principale raison pour laquelle l'équipe du noyau refuse des bug reports avec des noyaux teintés par du proprio : on ne sait jamais si on a affaire a du code de goret qui fait n'importe quoi (comme ici, tiens).