Plop.
Suite à une demande de blibli, voici un petit topo sur la configuration de mon kernel. En topic pour ouvrir le débat.

Je suis parti d'un Debian sid IA32 "normal" (en fait ça fait des années que je le mets à jour et que je le récupère même quand je change de bécane, donc à l'origine c'était bien sur une machine 32 bits)

Un jour j'ai voulu compiler un petit "Hello, world" en 64 bits pour voir. C'est très facile, il suffit de rajouter -m64 comme option de gcc. Mais pas moyen de le démarrer (exec format error ou quelque chose du genre).

Pas de souci me dis-je, yaka installer un kernel 64 bits, car celui-ci peut exécuter indifféremment des programmes 32 ou 64 bits. Apt refusa gentiment de faire cette installation puisqu'il considère IA32 et x86_64 comme des architectures distinctes. Mais je n'avais pas non plus envie de réinstaller un Debian complet en 64 bit: pas sûr de retrouver les quelques logiciels non libres tels flashplayer en version linux 64bit.

Recompiler mon kernel ne m'a jamais fait peur, mais il a fallu que je cherche un peu comment faire, car point d'option x86_64 dans mon make menuconfig.
La solution: make ARCH=x86_64 dans le directory linux. Oui c'est tout. Et il ne faut le faire qu'une fois, dès qu'on tourne sur un kernel 64 bit, ce n'est plus de la compilation cross-architecture.

Après, il faut juste booter ce truc avec grub et croiser les doigts... Dans mon cas, je n'ai pas eu le moindre pépin: tout mon user space a continué à se comporter comme avant, comme si rien n'avait changé. Par contre, mon "Hello, world" 64 bits s'exécute parfaitement lui aussi.

Avantages:
- un kernel 64 bits n'a aucun souci pour gérer la totalité de la RAM, et n'est pas limité à 2GB ou 3GB ou n'est pas moins performant s'il y en a plus;
- pour le principe: j'ai un processeur 64 bits, il mérite d'être traité comme tel, et non comme un vieux 80386;
- pour apprendre: regarder le code assembleur x86_64 généré par gcc est toujours instructif;
- pour jouer à faire un malloc de 20GB et y parsemer quelques données;
- certains programmes gagnent en performance en 64 bits: des number crunchers comme OpenSSL, ou des SGBD
- le kernel lui-même est sans-doute plus performant pour certaines choses (file system, p.ex.)

Inconvénients:
- les exécutables sont significativement plus gros, en terme de taille d'exécutable, mais aussi en terme d'occupation RAM (tous les int et pointeurs sont deux fois plus grands p.ex...)
- leur chargement est donc proportionnellement plus long aussi;
- toutes les librairies que l'on veut utiliser aussi en 64 bits doivent être installées en double (dans /usr/lib et dans /usr/lib64) et compilées maison, car apt ne veut pas les installer (logique car il n'y a pas de /usr/lib64 sur une architecture x86_64...), et il n'y a que quelques librairies 64 bits disponibles dans le repository IA32.
- installer une JVM depuis le site de Sun donne la surprise d'installer une version 64 bits (car la machine s'identifie comme telle: "Mozilla/5.0 (X11; U; Linux i686 (x86_64); ..."). Le problème est que la JVM a besoin de librairies (comme libX11) qui ne sont pas installées en version 64 bits. Il faut donc aller chercher la JVM 32 bits quivabien à la main.

Ma config hybride est donc à mon sens un compromis intéressant, combinant les avantages du kernel 64 bits sans les inconvénients des exécutables 64 bits. À ma connaissance, à part avec un linux from scratch ou peut-être un Gentoo tiouné, il n'y a pas de distro qui propose ce compromis.

Edit: utilisation incorrecte de IA64

SUPER!!
Merci beaucoup pour ton temps...

En effet, j'avais lu dans la shoot un jour que ta config était quelques peu non-orthodoxe.

Me voici fixé.


Les sources vanilla du kernel sont donc tout à fait cross-plateform? pas besoin d'en télécharger d'autres ou de patcher? juste le flag CC qui va bien?



Mais c'était prévisible? coup de bol? effet de bord agréable? théoriquement normal?



Plus besoin de PAE alors? ni HIGHMEM?


Ce qui est le cas de toutes les nouvelles générations d'intel et Amd, non?


Ces nouveaux processeurs sont tous équipés de registres 64bits, qui, a l'image de nos cerveaux, ne sont utilisés qu'à ....50%, c'est bien cela?
Mais - ca chipotte l'électronicien que je suis - toutes les lignes d'adressages I/O continuent d'être accédées en 32b? Comment le CPU "sait" qu'il doit leur parler en 32Bits?
D'ailleurs pour être adressé en 64bits, il leur faudrait "quelques lignes de cuivre" en plus, correct? On parle alors de toute une architecture HW 64bits? Et là plus le choix, faut un OS i64 _only_ ?


Mais...là tu veux dire que tu ne t'es pas limité à recompiler ton kernel?
Ou bien tu parles des exexcutables que _tu_ crées ? en les comparant à des compil' précédentes? Et tiens au fait, pour compiler ton petit programme, tu as continué simplement avec le -m64?plus nécessaire parce que la machine est reconnue comme 64 pure souche?


Là, de nouveau, c'est si on veut utiliser des applic 64? Dans le cas d'un simple kernel "64" ds un monde "32", cette démarche est-elle nécessaire aussi?

Tout à fait cross-platform est un grand mot, car si tu veux compiler un kernel pour ARM ça ne va pas marcher aussi simplement
Mais pour x86_64, c'est bon.


Prévisible et normal bien sûr.


Nope, ces options disparaissent d'ailleurs du menuconfig.


La je ne suis pas le meilleur spécialiste. J'ai juste vérifié pour mon CPU, fais pareil.


Ça dépend de ce que fait to CPU. C'est pour cela que les softs qui peuvent pleinement utiliser les opérations 64 bits profitent le plus du changement.



Tu peux avoir un CPU 64 bits en interne avec un bus hardware 32 bits. Mais même avec un bus hardware 64 bits, comme to CPU a un mode 32 bits, il saura très bien s'en servir aussi. Le Core 2 a un data path de 64 bits, ce qui ne l'empêche en rien de fonctionner en mode 32 bits.



Le -m64 est toujours nécessaire, parce que mon compilateur n'a pas changé, ni sa config par défaut. Et je parlais biens des exécutables 64 bits que je crée(rais) volontairement ainsi, ce qui n'est généralement pas le cas. La liste des inconvénients du user space 64 bits est essentiellement là pour justifier ma config hybride.




Non, pas du tout.

OK.
Lorsque je lance la compile du kernel (make ARCH=x86_64), je me prends toutes les questions de nivellement de la config (alors que j'avais bien lancé un menuconfig avant...)
Est-ce que l'option ARCH=x86_64 doit être fournie lors du make install?
--> make ARCH=x86_64 install
et pour l'installation des modules?
--> make ARCH=x86_64 make modules_install

Quid du Mkinitrd?

J'essayerais bien sous un Gentoo, mais la compilation ne va pas très loin...

Je lis souvent que pour ce faire sous Gentoo, il faut utiliser l'outil kgcc64, je regarderais un peu plus si j'ai le temps...

C'est normal que tu doives convertir ton ancienne config vers une nouvelle puisque les options ne sont pas les mêmes: p.ex. le IA32 a une option HIGHMEM et le x86_64 a une option "IA32 emulation"

Tu réponds une fois à toutes les questions par un <return> qui prend l'option par défaut puis tu refais un "make ARCH=x86_64 menuconfig" si tu veux refaire le tour des options nouvelles. Enfin tu fais ton build toujours avec le ARCH=x86_64, c'est en fait quand tu tournes déjà sur un kernel 64 bits que tu n'as plus besoin de préciser le ARCH évidemment (je vais corriger mon post initial).

Pas sûr que le ARCH soit strictement nécessaire pour l'install et le modules_install, mais il ne mange pas de pain tant que tu es sur ta config 32 bits...

Moi je n'utilise pas le mkinitrd (tout ce dont j'ai besoin pour booter est dans mon kernel), mais il ne devrait pas y avoir de problème a priori.

MMh très exactement ce que j'ai fait (un mkinitrd en plus, on ne sait jamais, mais en général je mets tout ce que je peux/veux "en dur" aussi..)

Je me choppe:


Ce qui est communément documenté comme:

Et non pas un module manquant, comme le message pourrait le laisser supposer.

Y a donc encore une incompatibilité entre i32/i64 dans mon bazard...


EDITH:
Allez soyons fou et testons:

SOLVED!

Or donc, dans ton How-To, préciser les options décrites dans mon post précédents pour les gros nigauds comme moi qui s'en tiennent _vraiment_ à la lattre de ce que tu dis...

Encore merci!

c'est bizarre mais pour moi ce post est soit en chinois, soit en mode Kernel#129

Hop, une petite digression, mais je trouvais que le sujet balançais un peu trop d'IA32 et d'IA64 de tous les côtés.

IA32, pour Intel Architecture 32 bits et le jeu de commandes standards pour les processeurs 32bits depuis le 386 (donc on l'appelle aussi x86 ou i386).

IA64 est la précédente appellation des processeurs Itanium d'intel. Ils sont rares, uniquement vendus dans des serveurs d'HP, et tout à fait incompatibles avec le reste, car il n'y à QUE les itaniums qui supportent cette architecture.

X86-64 est l'architecture crée par AMD (aussi appelée amd64) et se veut une évolution douce du 32bits vers le 64 bits, au contraire de l'approche radicale d'intel. AMD a réussi à imposer cette architecture, forçant intel à la reprendre (EM64T ou encore IA-32e), tandis que microsoft se contente de l'appeler x64

Alors attention, j'imagine déjà le nombre de pauvres âmes qui ont téléchargés des images IA64 pour installer leur petit débian sur leur core2 et se demandant pourquoi rien ne fonctionne.. c'est l'AMD64 qu'il faut choisir.
Et vu la compatibilité du jeu d'instruction AMD64 avec le i386 (puisqu'il ne fait que l'enrichir avec des commandes 64bit), il n'est pas étonnant de pouvoir faire tourner un userland en 32bit dessus, le seul souci seraient les éventuelles bibliothèques utilisées par des logiciels plus conséquent, impossible de cumuler les architectures à ce niveau. Donc à la longue, je dirais que c'est un peu risqué.

J'ai encore deux questions electro-philosophiques:

1./ En passant en 64bits, on peut dépasser l'adressage théorique des 4Go de RAM (3.3 en réalité sans l'espace réservé au HW...) sans utiliser la Physcial Address Extension (PAE) des kernel 32bits... Mais quelle est la difference réele puisque le data-path reste en 32bits? le kernel (et donc le CPU) a beau savoir maintenant compter jusqu'à 64Bits, il n'a tjrs pas les moyens 'physiques' d'adresser la RAM en 64....donc ca reste un petit 'workaround' purement soft? Quelle différence alors (perf?) par rapport à la PAE du 32bits?
(il faut probablement rentrer légèrement dans les algorithmes de l'un et de l'autre pour pouvoir répondre à cela... )

2./ On peut en effet maintenant faire un malloc() de 20Go théorique. Mais cela signifie que sur mes serveurs pourvus "seulement" de 8Go de RAM, cet exemple ne peut marcher sans aller creuser dans la /swap (qui elle doit alors faire >12Go..), correct?

Si je mes sources sont fiables, les proc 64 adressent la memoire sur 40(AMD, Core i7) ou 36 bits(Core 2).

Tout les 64 bits sont compatible PAE mais je ne sais pas si l'option est forcée ou si elle est inutilisée dans linux
edit: je parle de PAE sur les adresse 64b.

kort> en général elle n'est pas forcée: je dois tjrs la mettre à la main pour profiter des 4Go de Ram de mon PC...sinon, comme d'hab, il n'en voit que 3,3Go...

Pour les Gentooiste (ou pour le sake du patrimoine..):

Je ne m'explique pas pq il entre dans une démarche de cross-compiling alors que sous debian c'est de la compilation native...

berzemus> autant pour moi, j'ai utilisé IA64 de façon tout à fait inappropriée là où je devais dire x86_64

blietaer> ce qui manquait chez toi, c'était l'émulation IA32 ?

blietaer2> le malloc de 20 GB n'occupera de la mémoire physique puis virtuelle que quand tu l'utiliseras en écrivant dedans.

Je parlais de PAE en 64bits dont l'option n'existe pas.
Ca peut avoir de l'importence sur un système avec moult cartes graphiques qui ont moult memoires.

Ca fait donc quelques semaines que je peux apprécier le fait d'avoir un kernel 64 sur mes serveurs.

Je voudrais pousser l'expérience sur mes desktops (kubuntu, pour un exemple du commun des mortels), tout se passe bien ...jusqu'au moment ou je voudrais installer le driver NVIDIA.

Comme tjrs: 3 possibilités
a.) apt-geter gentillement les drivers NVIDIA de la distro (ce qui est foireux puisque celle-ci ignore tout à fait la petite touche 64 exotique du kernel..., donc in-modprodable...)
b.) apt-geter gentillement les sources du driver NVIDIA de la distro (bah..idem en fait..)
c.) aller à la pêche aux NVIDIA*.run sur le site du même nom (applaudissement au passage pour leur très large support de l'OS au pingouin), mais là, en prenant soin de selectionner QUE du 64, le package s'auto-dépaquète, mais s'arrête sur l'erreur : "./nvidia-installer: not found" (sans doute parce que problème entre userland 32 et kernel 64?)

Quelle autre possibilité?

A partir du NVIDIA*.run:
Je sais que pour compiler le drv X.org en 32 avec un kernel 64, Il y a un truc fourbe a faire avec les option avancés de l'installeur.
Il me semble même que tu es obligé de le décompresser à la main avant de lancer le fameux nvidia-installer
A partir des pkg:
Il n'y a pas un pkg Nvidia kernel source ??? que tu peux recompiler?

Les drivers propriétaires, c'est le mal

Le nvidia-installer, tu l'as ? Parce que le message dit que tu ne l'as pas, pas qu'il n'est pas compatible avec ton kernel...

Mais surtout, ton driver nvidia doit s'intégrer avec un xorg. Ton xorg est 64 bit ?

Sans doute que nvidia n'a pas prévu que les drivers kernel puissent être 64 bits alors que les drivers xorg restent 32 bits. Il feraient mieux de faire comme intel, et de publier leurs interfaces (qui ne peuvent quand-même pas contenir tant de secrets que ça).

Bonne chance.

Il n'y a pas de problème à avoir le drv kernel en 64bit et le drv X.org en 32bit (Déja testé avec un chroot de mon ancien disque (32) sur mon nouveau systeme (64))

kort> bien sûr, mais avec nvidia aussi ?

Sinon, en bootant un kernel 32 bit pour installer le driver xorg, puis en rebootant en kernel 64 bits pour installer le driver kernel, ça peut peut-être le faire...

oui, avec Nvidia.
je partais d'un systeme full 64 donc pas de problème pour le module kernel installé avec le .run mais sur la partition 32 chrooté ça a été plus compliqué.

sur le système chrooté, j'ai retrouvé quelques commandes qui pourrai servir mais sans garantie
:
./NVIDIA-Linux-x86-185.18.36-pkg1.run -x
cd /home/kort/download/NVIDIA-Linux-x86-185.18.36-pkg1
./nvidia-installer -help
./nvidia-installer -A
./nvidia-installer --no-kernel-module