Erreur de compilation conflicting types

Salut lenainjaune,

Je ne sais pas de quel historique d'un précédent fil tu parles :-)

Cela dit, je pense que ton problème est lié au fait que tu ne disposes pas d'un système Linux avec un noyaux, et les headers correspondants, compatibles avec le module que tu tentes de compiler.

En général, dans les erreurs de compilation, c'est le premier warning ou erreur qui est le plus pertinent.

Une recherche sur elixir.bootlin.com montre que, dans le noyau Linux, c'est l'entête dma-buf-map.h qui définit struct dma_buf_map (voir mon edit ci-dessous*).

La sortie de ton make montre que tu as un kernel 5.10.0-20-amd64.

Dans cette version du kernel, dma-buf-map.h n'existe pas et struct dma_buf_map n'est définie nulle part.

https://elixir.bootlin.com/linux/v5.10.194/source/include/linux/dma-buf-map.h

Cet entête semble exister et définir struct dma_buf_map à partir du kernel 5.11.

https://elixir.bootlin.com/linux/v5.11/source/include/linux/dma-buf-map.h#L115

Je pense qu'il te faut une version plus à jour du kernel et de ses entêtes pour compiler ce module.

---

* Edit : après recherche plus détaillée, il semble que ce soient les versions 5.11 à 5.17 du noyau Linux qui contiennent dma-buf-map.h

struct dma_buf_map c'est pas définie dans les versions 5.18 et 5.19 du noyau, ni dans les versions 6 du noyau qui est la dernière version majeure en cours de développement.

Bonjour,

En théorie tu es sensé installer tes headers de noyaux et le nécessaire pour compiler comme suit :

sudo apt update
sudo apt install build-essential make linux-headers-amd64

Concernant la remarque de [Dal], cette structure semble toujours exister dans les headers du noyau actuel (6.4.0-3) en Debian testing :

/usr/src/linux-headers-6.4.0-3-common/include/linux/dma-buf.h
 

struct dma_buf {
    /**
     * @size:
     *
     * Size of the buffer; invariant over the lifetime of the buffer.
     */
    size_t size;

    /**
     * @file:
     *
     * File pointer used for sharing buffers across, and for refcounting.
     * See dma_buf_get() and dma_buf_put().
     */
    struct file *file;

    /**
     * @attachments:
     *
     * List of dma_buf_attachment that denotes all devices attached,
     * protected by &dma_resv lock @resv.
     */
    struct list_head attachments;

    /** @ops: dma_buf_ops associated with this buffer object. */
    const struct dma_buf_ops *ops;

    /**
     * @vmapping_counter:
     *
     * Used internally to refcnt the vmaps returned by dma_buf_vmap().
     * Protected by @lock.
     */
    unsigned vmapping_counter;

    /**
     * @vmap_ptr:
     * The current vmap ptr if @vmapping_counter > 0. Protected by @lock.
     */
    struct iosys_map vmap_ptr;

    /**
     * @exp_name:
     *
     * Name of the exporter; useful for debugging. See the
     * DMA_BUF_SET_NAME IOCTL.
     */
    const char *exp_name;

    /**
     * @name:
     *
     * Userspace-provided name; useful for accounting and debugging,
     * protected by dma_resv_lock() on @resv and @name_lock for read access.
     */
    const char *name;

    /** @name_lock: Spinlock to protect name access for read access. */
    spinlock_t name_lock;

    /**
     * @owner:
     *
     * Pointer to exporter module; used for refcounting when exporter is a
     * kernel module.
     */
    struct module *owner;

    /** @list_node: node for dma_buf accounting and debugging. */
    struct list_head list_node;

    /** @priv: exporter specific private data for this buffer object. */
    void *priv;

    /**
     * @resv:
     *
     * Reservation object linked to this dma-buf.
     *
     * IMPLICIT SYNCHRONIZATION RULES:
     *
     * Drivers which support implicit synchronization of buffer access as
     * e.g. exposed in `Implicit Fence Poll Support`_ must follow the
     * below rules.
     *
     * - Drivers must add a read fence through dma_resv_add_fence() with the
     *   DMA_RESV_USAGE_READ flag for anything the userspace API considers a
     *   read access. This highly depends upon the API and window system.
     *
     * - Similarly drivers must add a write fence through
     *   dma_resv_add_fence() with the DMA_RESV_USAGE_WRITE flag for
     *   anything the userspace API considers write access.
     *
     * - Drivers may just always add a write fence, since that only
     *   causes unnecessary synchronization, but no correctness issues.
     *
     * - Some drivers only expose a synchronous userspace API with no
     *   pipelining across drivers. These do not set any fences for their
     *   access. An example here is v4l.
     *
     * - Driver should use dma_resv_usage_rw() when retrieving fences as
     *   dependency for implicit synchronization.
     *
     * DYNAMIC IMPORTER RULES:
     *
     * Dynamic importers, see dma_buf_attachment_is_dynamic(), have
     * additional constraints on how they set up fences:
     *
     * - Dynamic importers must obey the write fences and wait for them to
     *   signal before allowing access to the buffer's underlying storage
     *   through the device.
     *
     * - Dynamic importers should set fences for any access that they can't
     *   disable immediately from their &dma_buf_attach_ops.move_notify
     *   callback.
     *
     * IMPORTANT:
     *
     * All drivers and memory management related functions must obey the
     * struct dma_resv rules, specifically the rules for updating and
     * obeying fences. See enum dma_resv_usage for further descriptions.
     */
    struct dma_resv *resv;

    /** @poll: for userspace poll support */
    wait_queue_head_t poll;

    /** @cb_in: for userspace poll support */
    /** @cb_out: for userspace poll support */
    struct dma_buf_poll_cb_t {
        struct dma_fence_cb cb;
        wait_queue_head_t *poll;

        __poll_t active;
    } cb_in, cb_out;
#ifdef CONFIG_DMABUF_SYSFS_STATS
    /**
     * @sysfs_entry:
     *
     * For exposing information about this buffer in sysfs. See also
     * `DMA-BUF statistics`_ for the uapi this enables.
     */
    struct dma_buf_sysfs_entry {
        struct kobject kobj;
        struct dma_buf *dmabuf;
    } *sysfs_entry;
#endif
};

En supposant que cette structure soit celle attendue par ton pilote, deux solutions possibles:

1) Migrer vers une Debian plus récente

Attention ce n'est pas une opération anodine, donc pense à sauvegarder les documents auxquels tu tiens avant de te lancer.

Si tu es prêt à migrer, corrige /etc/apt/sources.list, par exemple comme suit pour aller vers Debian testing (= trixie, actuellement) :

deb http://ftp.fr.debian.org/debian/ testing main contrib non-free-firmware
deb http://security.debian.org testing-security main contrib non-free-firmware
deb http://ftp.fr.debian.org/debian/ testing-updates main contrib non-free-firmware

... puis lance :

sudo apt update
sudo apt upgrade

De toute façon... il faudra le faire tôt ou tard :-)

2) Installer uniquement un noyau plus récent

Si la migration te fait peur, tu peux télécharger les paquets à la main sur packages.debian.org puis les installer avec dpkg -i.

• linux-image-amd-64
• linux-headers-amd64

wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_6.4.11-1_amd64.deb
wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-headers-amd64_6.4.11-1_amd64.deb
sudo dpkg -i linux-*-amd64.deb

(en espérant que toutes les dépendances soient déjà installées !)

3) Solution intermédiaire : /etc/apt/preferences

La difficulté avec la solution (2), c'est que parfois, récupérer les dépendances est particulièrement laborieux (ça ne devrait pas arriver dans ton cas). L'idée est alors de référencer dans /etc/apt/sources.list les dépôts actuels et en plus les dépôts auxiliaires (e.g. ceux de debian testing). Cela revient donc à copier coller les lignes dont j'ai parlé dans la solution (1) à la suite du contenu actuel de ton fichier.

Afin de dire à APT de privilégier les paquets fournis par debian testing sous certaines conditions, on définit un fichier dans /etc/apt/preferences.d/ avec un nom arbitraire un minimum parlant (dans ton cas, ce pourrait être /etc/apt/preferences.d/ms9120 puisque c'est le nom du module que tu tentes de compiler.

Bonne chance

Bonjour,

Je suis d'accord avec vos retours / réponses / conclusions [Dal] et lenainjaune. Juste un point :

Donc si je comprends bien, je ne peux pas adapter le code pour qu'il fonctionne avec mon noyau actuel

Si mais il faut comprendre comment remplacer la structure manquante dma_buf_map par sa remplaçante. Ça force à avoir des connaissance en programmation kernel, comprendre pourquoi cette structure a disparu, et comment on s'y prend avec un noyau plus récent. 

Si j'en crois cet échange, c'est apparemment parce que la structure a été renommée en iosys_map (de même que toutes les fonctions préfixées dma_buf_map_* voient leur préfixe corrigé en conséquence). Si c'est bien le cas, il suffirait de corriger le code de ton pilote pour tester la version du kernel et abstraire ces symboles.

Ça fait longtemps que j'en n'ai pas fait de programmation kernel, mais en s'inspirant cette discussion tu pourrais écrire corriger chaque occurrence de :

#include <linux/dma-buf-map.h>

en : 

#ifdef __linux__
#  if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0)
#    include <linux/dma-buf-map.h>
#  else
#    include <linux/iosys-map.h>
#    define dma_buf_map iosys_map
#    define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR
#    define dma_buf_map_set_vaddr iosys_map_set_vaddr
#    define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem
#    define dma_buf_map_is_equal iosys_map_is_equal
#    define dma_buf_map_is_null iosys_map_is_null
#    define dma_buf_map_is_set iosys_map_is_set
#    define dma_buf_map_clear iosys_map_clear
#    define dma_buf_map_memcpy_to iosys_map_memcpy_to
#    define dma_buf_map_incr iosys_map_incr
#  endif
#endif

Pour quelque chose de plus propre, tu pourrais déporter cette section de code dans un header dans le dossier du module que tu tentes de compiler (appelons le my-dfa-buf-map.h) et du coup, remplacer :

#include <linux/dma-buf-map.h>

par :

#include "my-dma-buf-map.h"

Tout ceci part du principe que ça n'est qu'une histoire de renommage...

Bonne chance 

Si tu trouves la tache d'éditer les fichiers du projet pour y appliquer les changements proposés par mamiemando en #10 rebutante ou que tu n'est pas sûr de toi, tu peux utiliser find et sed pour faire les changements en dur appliquant les modifications en lançant cette ligne.

Cela donne ceci sur une seule ligne, avec GNU sed et find de ton système Linux :

find . -type f -not -path "./.git" -name "*.*" -exec sed -i 's/dma-buf-map.h/iosys-map.h/g; s/dma_buf_map/iosys_map/g; s/DMA_BUF_MAP_INIT_VADDR/IOSYS_MAP_INIT_VADDR/g; s/dma_buf_map_set_vaddr/iosys_map_set_vaddr/g; s/dma_buf_map_set_vaddr_iomem/iosys_map_set_vaddr_iomem/g; s/dma_buf_map_is_equal/iosys_map_is_equal/g; s/dma_buf_map_is_null/iosys_map_is_null/g; s/dma_buf_map_is_set/iosys_map_is_set/g; s/dma_buf_map_clear/iosys_map_clear/g; s/dma_buf_map_memcpy_to/iosys_map_memcpy_to/g; s/dma_buf_map_incr/iosys_map_incr/g; ' {} \;

Le résultat est théoriquement un code qui devrait compiler sur un système récent ayant un noyau et les entêtes du noyau supportant la nouvelle API iosys-map.h (à partir de v5.18), si les changements sémantiques sont correctement identifiés et que les changements se limitent à cela.

Le code ainsi modifié ne compilerait pas sur un système utilisant l'ancienne API dma-buf-map.h en revanche (à la différence la solution de mamiemando qui propose des directives de compilation distinguant les versions du noyau).

Bonjour

J'ai créé une commande multi-lignes principalement pour appliquer les correctifs que tu proposes sans avoir à éditer manuellement les fichiers (je garde le canevas pour des futurs projets et j'essayerais d'affiner pour trouver une version moins usine à gaz et je l'espère avec une meilleure lisibilité :D ). Si tu as des solutions d'écriture ou de commandes plus pratiques, je suis toute ouïe.

Comme je l'ai dit dans #10, la solution la plus propre/simple serait de mettre les #define que je propose dans un header et de faire en sorte que ces #define soient appliqués à l'ensemble des fichiers impliqués dans ton module.

J'avais proposé "my-dma-buf-map.h" (nom arbitraire). Dans le cas particulier de ton module, comme le fichier ms912x.h est inclu partout, il suffit donc de rajouter au début de "ms912x.h" la directive :

#include "my-dma-buf-map.h"

Note que tu pourrais aussi simplement directement le contenu de "my-dma-buf-map.h" dans "ms912x.h". Si tu envisages de proposer tes modifications dans un pull request GitHub, ce serait sans doute d'ailleurs le mieux, car il n'y a pas vraiment de raison de déporter ces considérations en dehors de "ms912x.h". Le seul intérêt de garder la séparation, c'est de séparer toutes nos corrections du code existant plutôt que charcuter à droite à gauche le code.

Je vous propose le cheminement qui a presque abouti pour installer en prenant en compte les propositions de mamiemando et [Dal], qui donnent approximativement le même résultat mais je ne suis pas assez calé pour déterminer les différences.

Les deux solutions sont équivalentes, mais différentes dans leur réalisation. Pour rappel, quand on compile un programme, il y a en réalité plusieurs étapes :

1. la précompilation (qui ne fait que résoudre les instructions précédées d'un #) : ce ne sont que des tâches "simples" (#include = copier coller ; #define = renommage, etc.)
2. la compilation : chaque fichier .c précompilé est converti sous forme de .o
3. le linkage : les .o sont rassemblés pour former le binaire finale (par exemple un exécutable, ou une librairie (.so ou .a), ou un module (.ko)).

Revenons aux deux solutions que nous t'avons proposé :

• Dans #10, je propose à l'aide de #define de laisser le pré-compilateur faire le renommage ;
• Dans #17, [Dal] propose de faire le boulot du pré-compilateur en corrigeant les sources avec sed (on est donc encore avant la précompilation puisqu'on n'a même pas encore appelé gcc à ce stade) ;
• Dans les deux cas, une fois l'étape de précompilation passée, on aboutit donc au même code source, et c'est pour ça que du point de vue de la compilation.

Parlons brièvement des avantages / inconvénient des deux solutions.

• L'inconvénient de #17, c'est qu'il faut faire ou non la manipulation selon la version du noyau, alors que dans #10 on laisse le compilateur vérifier la version du noyau et en fonction de ça, de faire le renommage est nécessaire ou non. C'est d'ailleurs l'opportunité de faire le

  "#include <drm/drm_edid.h>"

  ... uniquement si le noyau est dans une version qui fournit ce header (je te laisse regarder).

• L'inconvénient de #10, c'est qu'il faut rajouter le fichier supplémentaire et l'inclure partout, ce qui peut être rébarbatif si le module implique un grand nombre de fichiers. Mais dans le cas présent, ce n'est pas un gros problème, il suffit d'inclure "my-dma-buf-map.h" dans "ms912x.h".

sept. 09 01:00:53 vm-bookworm kernel: ms912x: module verification failed: signature and/or required key missing - tainting kernel

De ce que je vois ici, on dirait que tu n'as pas signé ton module. Je ne sais pas si c'est ce qui déclenche les erreurs qui suivent mais c'est possible.

Cette erreur est légitime si tu utilises un secure boot. En effet, Linux refuse alors de charger un module (.ko) s'il n'a pas été signé par une clé autorisée dans le BIOS.

Concrètement, cela oblige à créer une paire clé, l'enregistrer dans le BIOS (enroll), et l'utiliser pour signer le module (sign), puis redémarrer. J'ai détaillé toute la démarche dans ce tutoriel (voir section "Création de la paire de clés" et "Signature du module").

Le problème de signature d'un module se pose pour n'importe quel module que tu pourrais compiler, y compris ceux que tu compilerais au travers des paquets APT *-dkms. Pour rendre tout ça moins laborieux, les Debians récentes semblent générer une paire de clé (qu'il faut enrôler), mais ça n'est pas encore très clair,. Bref, au pire, tu te rabats sur le paragraphe précédent.

Bonne chance

Salut lenainjaune,

Le chargement du module échoue, et au motif que les symboles utilisés lors de la tentative de chargement du module drm_gem_shmem_dumb_create et drm_gem_shmem_prime_import_sg_table sont inconnus ou ne sont pas accessibles.

Ces symboles sont bien exportés par le noyau Linux 6.1, avec des directives EXPORT_SYMBOL_GPL() qui sont des macros qui rendent les symboles d'emblée accessibles à tout module indiquant une licence compatible GPL.

https://elixir.bootlin.com/linux/v6.1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L771

https://elixir.bootlin.com/linux/v6.1/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L771

(à partir des versions 5.2 du noyau)

Je suppose que tu tentes bien de charger le module sur un noyau 6.1.

De son côté, le module comprend bien une macro MODULE_LICENSE("GPL"); dans ms912x_drv.c

Une hypothèse pour ton problème pourrait alors être que le chargement échoue car ton module essaye d'accéder à une partie du noyau qui n'est pas chargée, et qui serai(en)t un(des) module(s) constituant une dépendance pour ton type de matériel.

Peux-tu faire un /usr/sbin/modinfo ./ms912x.ko pour voir ce que cela dit, notamment à la rubrique "depends:" ?

@[Dal] StatutContributeur

Je ne sais pas de quel historique d'un précédent fil tu parles :-)

Non, forcément puisqu'il n'a existé que jusqu'à ce que je clique bêtement sur un lien lors de sa prévisualisation :D, ce qui a ouvert le lien dans le même onglet et qui de fait m'a fait perdre tout le contenu du post que j'étais en train de rédiger (pour ceux à qui ça arrive, il existerait une solution qui consisterait à sauvegarder les données en mémoire vive pour le processus du navigateur - piste possible ici sous Linux et nécessite le paquetage gdb ; par ailleurs il existe aussi des addons tel celui ci pour Firefox qui conservent les données de formulaire).

Cela dit, je pense que ton problème est lié au fait que tu ne disposes pas d'un système Linux avec un noyaux, et les headers correspondants, compatibles avec le module que tu tentes de compiler.

J'en suis de plus en plus convaincu. Le noyau 5.10.0-20-amd64 sous Debian 11 donne comme première erreur error: conflicting types pour dma_buf_map d'après ton analyse car non géré par le noyau et là je viens de tenter la compilation sous Debian 12 avec le kernel 6.1.0-10-amd64 (voui j'ai des machines virtuelles toutes prêtes pour les tests, nul besoin de migrer un système ;-) ) :

root@vm-bookworm:~/ms912x-main# make
make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
  CC [M]  /root/ms912x-main/ms912x_registers.o
In file included from /root/ms912x-main/ms912x_registers.c:4:
/root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration
  113 |                                  const struct dma_buf_map *map,
      |                                               ^~~~~~~~~~~
  CC [M]  /root/ms912x-main/ms912x_connector.o
In file included from /root/ms912x-main/ms912x_connector.c:7:
/root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration
  113 |                                  const struct dma_buf_map *map,
      |                                               ^~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c: In function ‘ms912x_read_edid’:
/root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function)
   12 |         int offset = block * EDID_LENGTH;
      |                              ^~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c:12:30: note: each undeclared identifier is reported only once for each function it appears in
/root/ms912x-main/ms912x_connector.c: In function ‘ms912x_connector_get_modes’:
/root/ms912x-main/ms912x_connector.c:26:16: error: implicit declaration of function ‘drm_do_get_edid’ [-Werror=implicit-function-declaration]
   26 |         edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x);
      |                ^~~~~~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c:26:14: warning: assignment to ‘struct edid *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
   26 |         edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x);
      |              ^
/root/ms912x-main/ms912x_connector.c:28:15: error: implicit declaration of function ‘drm_add_edid_modes’ [-Werror=implicit-function-declaration]
   28 |         ret = drm_add_edid_modes(connector, edid);
      |               ^~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.build:255 : /root/ms912x-main/ms912x_connector.o] Erreur 1
make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:2037 : /root/ms912x-main] Erreur 2
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
make: *** [Makefile:15 : modules] Erreur 2

et je note que la 1ere erreur est error: ‘EDID_LENGTH’ undeclared différente de celle de Debian 11 et l'avertissement précédent est warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration

=> ça indique clairement que le changement de noyau a résorbé le problème cité dans mon 1er post mais que tout n'est pas résolu pour autant !

De plus dans la rubrique des questions du projet ms912x, après compilation quelqu'un a cette erreur insmod: ERROR: could not insert module ms912x.ko: Unknown symbol in module
from dmseg: et demande la version du noyau à utiliser pour compiler le programme avec succès, mais comme je l'ai dit, il y a peu d'activité sur le projet et il manque clairement d'information. Je ne dirais pas qu'il est abandonné mais sûrement en pause.

On avance ...

Une recherche sur elixir.bootlin.com montre que, dans le noyau Linux, c'est l'entête dma-buf-map.h qui définit struct dma_buf_map (voir mon edit ci-dessous*).

Je ne connaissais pas l'outil elixir.bootlin.com alors j'ai été faire un tour et j'ai testé comme ça dans quels kernels était utilisé EDID_LENGTH et d'après ce que je comprends il semble avoir été toujours supporté (ça me semble logique vu que EDID est - de mémoire, un protocole utilisé pour que les écrans puissent s'identifier auprès d'un système en utilisant comme support de transmission le câble vidéo donc même pour le VGA) mais là je ne comprends pas pourquoi il n’inclurait pas le header edid.h soit directement soit indirectement par un autre header, mais là je ne sais pas comment le déterminer ...

Aussi, d'après ce que dit la personne dans les questions du projet, on pourrait remplacer dma_buf_map par iosys_map et comme je ne comprenais pas pourquoi j'ai fait une recherche et trouvé ceci et en faisant les corrélations avec ton outil, j'en conclue ceci :

dma_buf_map (v5.11-rc1 -> v5.18-rc3)

iosys_map (v5.18-rc1 -> v6.5.1 actuellement)

C'est de la balle cet outil :D !

De plus, dans la rubrique des questions du projet il a aussi une personne qui demande la possibilité de pouvoir être compilé avec le noyau v6+ (qui doit donner un résultat analogue au mien - voir dessus).

=> par déduction : vu que dans le code on utilise dma_buf_map, je devrais tester tous les noyaux entre v5.11-rc1 et v5.18-rc3.

Ça semble confirmer ce que tu avances ...

Donc l'idée c'est de les tester un par un ?

Si je ne me trompe pas, il y a 308 noyaux candidats où existe dma_buf_map ...

Il n'y aurait pas moyen de réduire et cibler cette liste parce que bon j'ai autre chose à faire que de tester 300 kernels :( ?

Tu as besoin de ce module pour quoi exactement ?

Je ne voulais pas aborder le sujet, car je pense qu'il peut être polémique. J'ai acquis un adaptateur bon marché USB/VGA pour pouvoir facilement brancher un écran VGA supplémentaire par USB . J'ai réussi à le faire fonctionner sous Windows 10 en VM avec les pilotes livré sur support (aujourd'hui je n'y arrive plus, je ne comprends pas pourquoi et ne vais pas perdre de temps pour un système propriétaire) ; je caressais l'espoir de pouvoir faire de même sous Linux.

root@vm-bookworm:~/ms912x-main# lsusb | grep -i vga
Bus 001 Device 003: ID 534d:6021 MacroSilicon VGA Display Adapter

Ça et là je lis qu'on ne peut pas faire ça sous Linux, que personne ne développe de pilote, qu'il faut mettre le prix dans les équipements ou changer de solution matérielle ... jusqu'à ce que je trouve ceci qui semble parfaitement répondre à mes attentes puisque comme c'est indiqué dans la première phrase Linux kernel driver for MacroSilicon USB to VGA/HDMI adapter. VID/PID is 534d:6021. Device is USB2.0

Hein ! On dirait bien que c'est pile ce qu'il me faut ... :D

Donc la première étape c'est de réussir à compiler, la 2eme sera de charger et la 3eme de comprendre pourquoi ... l'affichage ne fonctionne pas pour autant :D (j'ai l'habitude sous Linux) et puis un jour peut être ça fonctionnera mais en tout cas j'aurais appris un tas de choses pour y arriver.

Voilà-voilà ... :D

@mamiemando StatutModérateur

1) Migrer vers une Debian plus récente

2) Installer uniquement un noyau plus récent

Pas besoin, pour l'instant je teste en VM

De toute façon... il faudra le faire tôt ou tard :-)

Ou ... pas ;D ! Je plaisante à moitié mais tant que je n'aurais pas réussi à trouver la bonne méthode pour migrer les applications, les réglages, je resterais sur Debian 11. Il faut dire que j'ai beaucoup de choses à migrer et que bon, le coup du "comme ça ne marche pas, il faut passer à la version n+1" oui dans la théorie, dans la pratique bof ! Pour l'anecdote avant d'installer Debian 11 sur mon PC perso j'étais sous Ubuntu 12.04 LTS et globalement ça fonctionnait très bien et j'ai pu vivre avec, jusqu'à il y a 2 ans je crois où les exigences logicielles m'ont contraint à changer de système !

wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-amd64_6.4.11-1_amd64.deb
wget http://ftp.fr.debian.org/debian/pool/main/l/linux-signed-amd64/linux-headers-amd64_6.4.11-1_amd64.deb
sudo dpkg -i linux-*-amd64.deb

(en espérant que toutes les dépendances soient déjà installées !)

Petite coquille :

sudo dpkg -i linux-*-amd64.deb

->

sudo dpkg -i linux-*amd64.deb

pas de tiret à gauche de amd64.deb sinon dpkg n'installera pas !

2) Installer uniquement un noyau plus récent

3) Solution intermédiaire : /etc/apt/preferences

Oui comme je l'ai dit à [Dal] je vais tenter de cibler les versions de kernel candidates.

  @[Dal] StatutContributeur

Tu pourrais te créer une machine virtuelle avec un Ubuntu 22.04 LTS pour tester.

J'ai installé la VM Ubuntu ce matin et je testerai l'installation du noyau ce soir quand je serai de retour.

Donc si je comprends bien, je ne peux pas adapter le code pour qu'il fonctionne avec mon noyau actuel ou alors il faudrait que j'adapte les parties d'un noyau opérationnel sur un autre noyau, mais là il faudrait que toutes les dépendances soient installées et ne soient pas en conflit. Ça me semble très galère d'avance voir peu possible :( (je ne pense pas que quelque chose puisse être réellement IMpossible :D) ...

J'ai une inspiration qui fait le lien entre plusieurs idées et technologies ...

Comme ça à la louche : je teste sur Ubuntu le noyau opérationnel et vois si la compilation réussit, au final si l'écran est détecté et que ça fonctionne, ensuite je tente d'installer ce noyau opérationnel sur le Debian "qui va bien" et voit si ça fonctionne aussi, si je trouve l'association fonctionnelle, peut être que je pourrais envisager de passer par un conteneur (entre autre si le passage de ce périphérique USB3 en passthrough est possible) pour au final avoir un noyau opérationnel autonome (de ce que j'ai compris les conteneurs sont plus réactifs et économes que les VMs, en utilisation des ressources d'espace de stockage, CPU, RAM) pour ensuite pouvoir être installé (en théorie) sur n'importe quelle distribution.

Cette direction m'enchante beaucoup car elle résoudrait beaucoup d'autres de mes projets :D

A suivre donc ...

Note : si tu te demandes pourquoi je cherche à tout prix à l'installer sur une distribution Debian plutôt que Ubuntu (son bébé quoi ;) ), je répondrais (sans lancer de polémique) que je suis extrêmement déçu par la direction commerciale que prend Canonical/Ubuntu depuis quelques années et que je boycotte cette distribution (même si par le passé j'en chantais ses louanges).

Comme ça à la louche : ... je tente d'installer ce noyau opérationnel sur le Debian "qui va bien" et voit si ça fonctionne aussi,

J'ai également réussi à compiler le module sur une VM Debian 11 après avoir compilé le noyau v5.15.0-43 en suivant ce tuto adapté pour la  v5.15.0-43 et après 3-4h de compilation (je pense que je vais étudier sérieusement la parallélisation et ajouter des CPUs à la VM, parce que c'est vraiment long ;) ), je constate que je peux charger le module sans erreur MAIS que l'écran n'est pas détecté ni en GUI ni en CLI. Mais bon je ne suis pas encore sûr que le problème n'est pas uniquement du à la virtualisation (vControleur USB2 ou 3, serveur d'affichage X/Wayland, etc.). Je vais tester sur un PC physique pour voir.

=> donc c'est "presque" un succès !

@[Dal] StatutContributeur

Les containers partagent normalement le même noyaux que l'hôte, alors je ne pense pas que tu puisses utiliser ce procédé.

Oups tu as raison :( ! J'étais tellement pris dans l'euphorie que j'ai fait des raccourcis. Apparemment, les containers n'embarquent pas leur noyau (à vérifier si ça n'est pas possible du tout). Du coup on revient à de la virtualisation ... et pour profiter d'un écran externe ça ne me parait pas le moyen le plus pratique (à voir !).

Comme mamiemando a trouvé le poste d'origine des mainteneurs du kernel qui acte des changements sur l'API :

https://lore.kernel.org/lkml/aa1312fc-197b-c1ab-6a18-369d49c1e8f8@xs4all.nl/t/

Oui, je l'avais aussi mentionné dans mes 1ers posts, car j'avais besoin de creuser pourquoi la personne avait remplacé dma_buf_map par iosys_map dans le code du module avec le kernel v5.19.0. Par contre pour être franc, je n'avais aucune idée de ce à quoi ça pouvait me servir et comment l'utiliser. Donc je vais essayer la proposition de mamiemando

=> par déduction : vu que dans le code on utilise dma_buf_map, je devrais tester tous les noyaux entre v5.11-rc1 et v5.18-rc3.

J'ai eu un retour dans la rubrique des questions du projet ms912x. Il serait possible à priori de compiler avec tous les noyaux entre v5.11 et v5.17.

Par ailleurs, toujours d'après ce contributeur, le serveur X ne serait pas ce qu'il y a de mieux pour permettre la gestion d'un écran supplémentaire avec ce module (encore une fois, j'obtiens les infos au compte goutte) et il vaudrait mieux utiliser Wayland d'après ce que je comprends.

Dans mon cas Ubuntu utilise Wayland et Debian utilise X11, c'est sans doute ça le problème de fond !

Le hic, c'est que mon environnement de bureau préféré/attitré est XFCE4 et qu'il ne gérerait Wayland que à partir de XFCE4 v4.18 et même plutôt v4.20 (sous Debian 11 XFCE4 est en v4.16 et on ne peut à priori pas faire de montée de version), de plus je n'ai pas réussi à faire que lightdm utilise xwayland (j'ai un peu survolé le sujet).

Je pense avoir rencontré la partie immergée de l'iceberg ...

De ce que je comprends, pour que ça marche, exit XFCE4/lightdm ...

Il faut que je creuse quand même ...

De ce que je comprends, pour que ça marche, exit XFCE4/lightdm ...

Pour ceux que ça intéresse, l'installation sur Debian 11 avec un noyau supporté (testé avec un noyau v5.15.43 compilé) et le trio Gnome/GDM/xWayland a réussi sans grande surprise et l'écran est détecté, toutefois dans mon environnement virtuel (Qemu/KVM) il y a un bug car une fois détecté la souris se comporte bizarrement.

@[Dal] StatutContributeur

Quand le compilateur envoie ce genre d'avertissement :

"In file included from /root/ms912x-main/ms912x_registers.c:4:
/root/ms912x-main/ms912x.h:113:19: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration"

où il t'avertit qu'il pense que tu déclares une struct dans les paramètres d'une fonction, cela signifie en réalité que le code compilé ne comprend pas la définition de la struct qui devrait se trouver ailleurs (normalement, dans un entête).

OK je garde cette info précieusement car le message du message est confondant !

Maintenant, le fait que le module fonctionne bien, avec tel ou tel gestionnaire de bureau ou service graphique peut être lié aux limitation du module lui-même, voire à des problèmes inhérents au noyau Linux utilisé et qui ont peut-être été résolus dans les versions plus récentes. Ces questions sont un peu loin du topic programmation C.

Oui complètement, je vais poursuivre mes investigations ailleurs et me recentrer sur la compilation du module ...

Tu pourrais alors contribuer le code du module modifié et rendre quelques autres internautes possédant le même matériel que toi heureux :-).

Si tu trouves la tache d'éditer les fichiers du projet pour y appliquer les changements proposés par mamiemando en #10 rebutante ou que tu n'est pas sûr de toi, tu peux utiliser find et sed pour faire les changements en dur appliquant les modifications en lançant cette ligne.

Proposition #10 de mamiemando :

root@vm-bookworm:~# diff ~/ms912x-main/ms912x.h ~/ms912x-main_origin/ms912x.h
8,26d7
< #include <linux/version.h>
< #ifdef __linux__
< #  if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0)
< #    include <linux/dma-buf-map.h>
< #  else
< #    include <linux/iosys-map.h>
< #    define dma_buf_map iosys_map
< #    define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR
< #    define dma_buf_map_set_vaddr iosys_map_set_vaddr
< #    define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem
< #    define dma_buf_map_is_equal iosys_map_is_equal
< #    define dma_buf_map_is_null iosys_map_is_null
< #    define dma_buf_map_is_set iosys_map_is_set
< #    define dma_buf_map_clear iosys_map_clear
< #    define dma_buf_map_memcpy_to iosys_map_memcpy_to
< #    define dma_buf_map_incr iosys_map_incr
< #  endif
< #endif
< 
137c118
< #endif
---
> #endif
\ Pas de fin de ligne à la fin du fichier

Note : LINUX_CODE_VERSION implique #include <linux/version.h> sinon il ne sera pas défini et on aura une erreur aussi confondante error: missing binary operator before token "("

root@vm-bookworm:~# uname -r
6.1.0-10-amd64
root@vm-bookworm:~# make
...
/root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function)
   12 |         int offset = block * EDID_LENGTH;
...

=> on obtient la même erreur que #6

La proposition de [Dal] #17 donne le même résultat

J'ai donc cherché sur l'erreur EDID_LENGTH et j'ai trouvé ceci et en survolant rapidement l'échange j'ai trouvé ceci qui propose d'ajouter le header #include <drm/drm_edid.h> ; j'ai testé de l'ajouter au ms912.h  et cette fois j'ai ceci :

root@vm-bookworm:~/ms912x-main# make
make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
  CC [M]  /root/ms912x-main/ms912x_registers.o
  CC [M]  /root/ms912x-main/ms912x_connector.o
  CC [M]  /root/ms912x-main/ms912x_transfer.o
  CC [M]  /root/ms912x-main/ms912x_drv.o
  LD [M]  /root/ms912x-main/ms912x.o
  MODPOST /root/ms912x-main/Module.symvers
  CC [M]  /root/ms912x-main/ms912x.mod.o
  LD [M]  /root/ms912x-main/ms912x.ko
  BTF [M] /root/ms912x-main/ms912x.ko
/bin/sh: 1: ./tools/bpf/resolve_btfids/resolve_btfids: not found
make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.modfinal:63 : /root/ms912x-main/ms912x.ko] Erreur 127
make[2]: *** Suppression du fichier « /root/ms912x-main/ms912x.ko »
make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:1954 : modules] Erreur 2
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
make: *** [Makefile:15 : modules] Erreur 2

Bon bref ! Je ne sais pas où je vais, il faudra que je revois ça à tête reposée.

@mamiemando StatutModérateur
 

après avoir compilé le noyau v5.15.0-43

• A priori tu n'as pas de raison de compiler le noyau toi-même, c'est tout l'intérêt du tandem offert par les paquets linux-image-amd64 et linux-headers-amd64. Il déploie un noyau compilé et les headers nécessaires pour compiler un module compatible avec ce noyau.

Oui je suis d'accord sauf que depuis certaines distributions (par exemple mon actuelle, Debian 11) je n'ai pas vraiment le choix (rappel : ma_buf_map v5.11-rc1 -> v5.18-rc3 et iosys_map v5.18-rc1 -> v6.5.1 actuellement).

root@vm-bullseye-xfce:~# apt-cache search linux-image | grep headers
linux-headers-5.10.0-20-amd64 - Header files for Linux 5.10.0-20-amd64
linux-headers-5.10.0-20-cloud-amd64 - Header files for Linux 5.10.0-20-cloud-amd64
linux-headers-5.10.0-20-rt-amd64 - Header files for Linux 5.10.0-20-rt-amd64
linux-headers-5.10.0-22-amd64 - Header files for Linux 5.10.0-22-amd64
linux-headers-5.10.0-22-cloud-amd64 - Header files for Linux 5.10.0-22-cloud-amd64
linux-headers-5.10.0-22-rt-amd64 - Header files for Linux 5.10.0-22-rt-amd64
linux-headers-5.10.0-25-amd64 - Header files for Linux 5.10.0-25-amd64
linux-headers-5.10.0-25-cloud-amd64 - Header files for Linux 5.10.0-25-cloud-amd64
linux-headers-5.10.0-25-rt-amd64 - Header files for Linux 5.10.0-25-rt-amd64

Bonjour,

Note : LINUX_CODE_VERSION implique #include <linux/version.h> sinon il ne sera pas défini et on aura une erreur aussi confondante error: missing binary operator before token "("

Effectivement.

/bin/sh: 1: ./tools/bpf/resolve_btfids/resolve_btfids: not found

Bizarre cette erreur. Le paquet libbpf-tools ne semble pas fournir cet exécutable. Regarde à tout hasard cette discussion.

je n'ai pas vraiment le choix (rappel : ma_buf_map v5.11-rc1 -> v5.18-rc3 et iosys_map v5.18-rc1 -> v6.5.1 actuellement)

Le but des #define que j'ai évoqué est précisément de lever cette contrainte en remplaçant les symboles obsolètes par les symboles actuels.

Bonne chance

Salut lenainjaune,

"resolve_btfids" est un outil utilisé lors de la compilation du noyau et apparemment de modules.

Il est bien dans Linux v6.1.0 que tu utilises :

https://elixir.bootlin.com/linux/v6.1/source/tools/bpf/resolve_btfids

mais je n'ai pas vu de paquets Debian qui le fournisse (ni en source ni en binaire).

Avec le code du noyau correspondant à Linux v6.1.0, tu pourrais compiler ce binaire.

https://github.com/torvalds/linux/tree/v6.1

Le code et le Makefile se trouvent donc dans tools/bpf/resolve_btfids

Ensuite, tu peux copier le binaire dans le répertoire de build du module à l'endroit attendu, comme proposé là :

https://aur.archlinux.org/packages/linux-git-headers?O=10#comment-836241

mkdir -p /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/
cp /tmp/mybuilddir/linux-git/linux-git/src/linux/tools/bpf/resolve_btfids/resolve_btfids /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/

(en remplaçant le 1er argument du cp par l'emplacement de ton binaire)

Des news ...

Installer le module ms912x sur Debian 12 sur le noyau par défaut (v6.1.0-10)

@[Dal] StatutContributeur

Skipping BTF generation for /root/ms912x-main/ms912x.ko due to unavailability of vmlinux

...

resolve_btfids" est un outil utilisé lors de la compilation du noyau et apparemment de modules. [...] Avec le code du noyau correspondant à Linux v6.1.0, tu pourrais compiler ce binaire.

J'ai suivi tes recommandations (nécessite le paquetage libelf-dev) mais ça n'a pas été suffisant pour éliminer l'avertissement, il a fallu suivre cette procédure (j'ai testé la solution 1 avec succès) et après l'avertissement a disparu. De plus cet avertissement n'est a priori par bloquant, donc on peut à priori l'ignorer (voir plus bas).

Au final, le module a été compilé avec succès MAIS au moment de le charger, j'ai eu une erreur "Unknow symbol in module" que je n'ai pas encore réussi à résoudre et de fait le module se charge pas (voir les détails dessous).

@mamiemando StatutModérateur

J'ai créé une commande multi-lignes principalement pour appliquer les correctifs que tu proposes sans avoir à éditer manuellement les fichiers (je garde le canevas pour des futurs projets et j'essayerais d'affiner pour trouver une version moins usine à gaz et je l'espère avec une meilleure lisibilité :D ). Si tu as des solutions d'écriture ou de commandes plus pratiques, je suis toute ouïe.

---

Je vous propose le cheminement qui a presque abouti pour installer en prenant en compte les propositions de mamiemando et [Dal], qui donnent approximativement le même résultat mais je ne suis pas assez calé pour déterminer les différences.

Préparations et récupération du code source

root@vm-bookworm:~# apt update

root@vm-bookworm:~# apt install -y build-essential gcc make cmake gettext git g++ intltool dbus-user-session vim sshfs

root@vm-bookworm:~# wget https://github.com/rhgndf/ms912x/archive/refs/heads/main.zip

root@vm-bookworm:~# unzip main.zip
Archive:  main.zip
86aac85d4347af8893c74cb8b7023187fc2e2f8b
   creating: ms912x-main/
  inflating: ms912x-main/.clang-format  
  inflating: ms912x-main/.gitignore  
  inflating: ms912x-main/Makefile    
  inflating: ms912x-main/README.md   
   creating: ms912x-main/captures/
  inflating: ms912x-main/captures/resolutions  
  inflating: ms912x-main/insmod.sh   
  inflating: ms912x-main/ms912x.h    
  inflating: ms912x-main/ms912x_connector.c  
  inflating: ms912x-main/ms912x_drv.c  
  inflating: ms912x-main/ms912x_registers.c  
  inflating: ms912x-main/ms912x_transfer.c  
  inflating: ms912x-main/registers   

root@vm-bookworm:~# cp -a ms912x-main ms912x-main_origin

root@vm-bookworm:~# cd ms912x-main

Les headers du noyau

root@vm-bookworm:~/ms912x-main# make
make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules
make[1]: *** /lib/modules/6.1.0-10-amd64/build : Aucun fichier ou dossier de ce type. Arrêt.
make: *** [Makefile:15 : modules] Erreur 2

# => headers du kernel absents


# solution : https://devicetests.com/fixing-ubuntu-error-no-such-file-or-directory
root@vm-bookworm:~# dpkg -l | grep $( uname -r )
ii  linux-image-6.1.0-10-amd64            6.1.38-1                           amd64        Linux 6.1 for 64-bit PCs (signed)

root@vm-bookworm:~# apt install -y linux-headers-$( uname -r )

root@vm-bookworm:~# dpkg -l | grep $( uname -r )
ii  linux-headers-6.1.0-10-amd64          6.1.38-1                           amd64        Header files for Linux 6.1.0-10-amd64
ii  linux-image-6.1.0-10-amd64            6.1.38-1                           amd64        Linux 6.1 for 64-bit PCs (signed)

Header manquant pour dma_buf_map

root@vm-bookworm:~/ms912x-main# make
make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
  CC [M]  /root/ms912x-main/ms912x_registers.o
In file included from /root/ms912x-main/ms912x_registers.c:4:
/root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration
  113 |                                  const struct dma_buf_map *map,
      |                                               ^~~~~~~~~~~
  CC [M]  /root/ms912x-main/ms912x_connector.o
In file included from /root/ms912x-main/ms912x_connector.c:7:
/root/ms912x-main/ms912x.h:113:47: warning: ‘struct dma_buf_map’ declared inside parameter list will not be visible outside of this definition or declaration
  113 |                                  const struct dma_buf_map *map,
      |                                               ^~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c: In function ‘ms912x_read_edid’:
/root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function)
   12 |         int offset = block * EDID_LENGTH;
      |                              ^~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c:12:30: note: each undeclared identifier is reported only once for each function it appears in
/root/ms912x-main/ms912x_connector.c: In function ‘ms912x_connector_get_modes’:
/root/ms912x-main/ms912x_connector.c:26:16: error: implicit declaration of function ‘drm_do_get_edid’ [-Werror=implicit-function-declaration]
   26 |         edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x);
      |                ^~~~~~~~~~~~~~~
/root/ms912x-main/ms912x_connector.c:26:14: warning: assignment to ‘struct edid *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
   26 |         edid = drm_do_get_edid(connector, ms912x_read_edid, ms912x);
      |              ^
/root/ms912x-main/ms912x_connector.c:28:15: error: implicit declaration of function ‘drm_add_edid_modes’ [-Werror=implicit-function-declaration]
   28 |         ret = drm_add_edid_modes(connector, edid);
      |               ^~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.1.0-10-common/scripts/Makefile.build:255 : /root/ms912x-main/ms912x_connector.o] Erreur 1
make[1]: *** [/usr/src/linux-headers-6.1.0-10-common/Makefile:2037 : /root/ms912x-main] Erreur 2
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
make: *** [Makefile:15 : modules] Erreur 2

root@vm-bookworm:~/ms912x-main# make clean
make -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main clean
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
rm -f /root/ms912x-main/Module.symvers /root/ms912x-main/*.ur-safe

Prise en charge du header dma_buf_map

Solution de mamiemando

Header sélectif selon version de noyau (voir #10)

Objectif de la commande multi-lignes : reproductibilité et éviter les erreurs

Remarque : \n = saut à la ligne (newline)

Notes sur l'écriture d'une commande multi-lignes complexe :

• ... | ... | ... : une multi-commandes pipée
• ( ... \n ... ) > temp : sortie d'une multi-commandes dans un fichier
• echo "..." > /dev/null : my DIY comment :D !
• ... \\n ... : commande multi-ligne (\ strict en dernier avant \n)
• cat <<'EOF' \n ... \n ... \n EOF : heredoc (simplifie l'écriture)
   ATTENTION : EOF doit être strictement le seul texte sur la ligne
• \ de fin stricte de ligne obligatoire sur lignes HORS heredoc

Notes sur les commandes :

• tac | ... | tac : permet de gérer par dernière correspondance
• tac -b : résout la gestion bizarre de la dernière ligne
    (évite d'avoir à rajouter manuellement une ligne à la fin de la
    commande en entrée)
• awk ...  { ... next } : empêche une correspondance suivante
• awk ... '...'\n'...' : multi-lignes (AUCUNES espaces autour du \n)
• ; de fin de ligne obligatoire entre les blocs de commandes pipées
• if [[ $( ! grep ... ) ]] ; then ... \n fi : empêche une insertion
    supplémentaire si elle est déjà en place

Note : pour comprendre l'organisation de la commande, télécharger le fichier ms912x.h depuis son archive ZIP

root@vm-bookworm:~/ms912x-main# \
src=ms912x.h ; \
(
echo "début précédé par \n -> dernier #include <linux/" > /dev/null ; \
echo ; \
cat $src | tac -b \
| awk '/^#include <linux\/.+>/ { print ; r = 1 ; next } r' \
| tac ; \
\
echo "insertion \n et header pour *VERSION* nécessaire" > /dev/null ; \
if [[ ! $( grep "#include <linux/version.h>" $src ) ]] ; then \
cat <<'EOF'

#include <linux/version.h>
EOF
fi
\
echo "autres #include -> dernier #define DRIVER_*" > /dev/null ; \
cat $src | tac -b \
| awk \
'  /^#define DRIVER_/ { print ; r = 1 ; next } '\
'  /^#include <linux\/.+>/ { exit } '\
'  r' \
| tac ; \
\
echo "ajout de la gestion par version de noyau" > /dev/null ; \
if [[ ! $( 
  grep "include <linux/dma-buf-map.h>" $src \
) ]] ; then cat <<'EOF'


#ifdef __linux__
#  if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0)
#    include <linux/dma-buf-map.h>
#  else
#    include <linux/iosys-map.h>
#    define dma_buf_map iosys_map
#    define DMA_BUF_MAP_INIT_VADDR IOSYS_MAP_INIT_VADDR
#    define dma_buf_map_set_vaddr iosys_map_set_vaddr
#    define dma_buf_map_set_vaddr_iomem iosys_map_set_vaddr_iomem
#    define dma_buf_map_is_equal iosys_map_is_equal
#    define dma_buf_map_is_null iosys_map_is_null
#    define dma_buf_map_is_set iosys_map_is_set
#    define dma_buf_map_clear iosys_map_clear
#    define dma_buf_map_memcpy_to iosys_map_memcpy_to
#    define dma_buf_map_incr iosys_map_incr
#  endif
#endif
EOF
fi
\
echo "... reste intouché" > /dev/null ; \
cat $src | tac -b \
| awk '/^#define DRIVER_/ { exit } 1' \
| tac \
) > temp

Vérification sommaire que la commande dessus donne le bon résultat et remplacer le contenu de ms912x.h par celui de temp

root@vm-bookworm:~/ms912x-main# diff ms912x.h temp
7a8,9
> #include <linux/version.h>
> 
21a24,42
> #ifdef __linux__
> #  if LINUX_VERSION_CODE < KERNEL_VERSION(6, 0, 0)
> #    include <linux/dma-buf-map.h>
> #  else
> #    include <linux/iosys-map.h>
...
> #    define dma_buf_map_incr iosys_map_incr
> #  endif
> #endif
> 
> 
118c139,140
< #endif
\ Pas de fin de ligne à la fin du fichier
---
> #endif
> 

root@vm-bookworm:~/ms912x-main# mv temp ms912x.h

Solution de [Dal]

Voir #17

root@vm-bookworm:~/ms912x-main# find . -type f -not -path "./.git" -name "*.*" -exec sed -i 's/dma-buf-map.h/iosys-map.h/g; s/dma_buf_map/iosys_map/g; s/DMA_BUF_MAP_INIT_VADDR/IOSYS_MAP_INIT_VADDR/g; s/dma_buf_map_set_vaddr/iosys_map_set_vaddr/g; s/dma_buf_map_set_vaddr_iomem/iosys_map_set_vaddr_iomem/g; s/dma_buf_map_is_equal/iosys_map_is_equal/g; s/dma_buf_map_is_null/iosys_map_is_null/g; s/dma_buf_map_is_set/iosys_map_is_set/g; s/dma_buf_map_clear/iosys_map_clear/g; s/dma_buf_map_memcpy_to/iosys_map_memcpy_to/g; s/dma_buf_map_incr/iosys_map_incr/g; ' {} \;

root@vm-bookworm:~/ms912x-main# diff -qr ~/ms912x-main ~/ms912x-main_origin/
Les fichiers /root/ms912x-main/ms912x.h et /root/ms912x-main_origin/ms912x.h sont différents
Les fichiers /root/ms912x-main/ms912x_transfer.c et /root/ms912x-main_origin/ms912x_transfer.c sont différents

root@vm-bookworm:~/ms912x-main# diff ~/ms912x-main/ms912x.h ~/ms912x-main_origin/ms912x.h
113c113
< 				 const struct iosys_map *map,
---
> 				 const struct dma_buf_map *map,

root@vm-bookworm:~/ms912x-main# diff ~/ms912x-main/ms912x_transfer.c ~/ms912x-main_origin/ms912x_transfer.c
160c160
< 				 const struct iosys_map *map,
---
> 				 const struct dma_buf_map *map,

Header manquant pour gestion EDID

Remarque : pour le détail de la commande multi-lignes voir les notes dessus dans la solution de mamiemando

root@vm-bookworm:~/ms912x-main# make
...
/root/ms912x-main/ms912x_connector.c:12:30: error: ‘EDID_LENGTH’ undeclared (first use in this function)
   12 |         int offset = block * EDID_LENGTH;
      |                              ^~~~~~~~~~~

root@vm-bookworm:~/ms912x-main# make clean

root@vm-bookworm:~/ms912x-main# \
src=ms912x.h ; \
(
echo "début précédé par \n -> dernier #include" > /dev/null ; \
echo ; \
cat $src | tac -b \
| awk '/^#include.+/ { print ; r = 1 ; next } r' \
| tac ; \
\
echo "insertion \n et header pour EDID" > /dev/null ; \
if [[ ! $( grep "#include <drm/drm_edid.h>" $src ) ]] ; then cat <<'EOF'

#include <drm/drm_edid.h>
EOF
fi
\
echo "... reste intouché" > /dev/null ; \
cat $src | tac -b \
| awk '/^#include <drm\/.+>/ { exit } 1' \
| tac \
) > temp

root@vm-bookworm:~/ms912x-main# grep drm/drm_edid.h temp
#include <drm/drm_edid.h>

root@vm-bookworm:~/ms912x-main# mv temp ms912x.h

root@vm-bookworm:~/ms912x-main# make
...
Skipping BTF generation for /root/ms912x-main/ms912x.ko due to unavailability of vmlinux
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »

Le problème de vmlinux manquant

Sur les conseils de [Dal], j'ai suivi ses instructions depuis #20

Avertissement : je ne sais pas si cette partie est nécessaire puisque le message du compilateur est un avertissement et NON une erreur. De plus, après tests, son absence n'empêche pas de générer le module compilé. Toutefois j'ai remarqué que les fichiers résultants sont différents selon si on gère vmlinux ou pas. Avis donc aux experts ...

root@vm-bookworm:~/ms912x-main# cd

root@vm-bookworm:~# wget https://github.com/torvalds/linux/archive/refs/tags/v6.1.zip

root@vm-bookworm:~# unzip v6.1.zip

root@vm-bookworm:~# cd linux-6.1/tools/bpf/resolve_btfids/

root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# make
  MKDIR     /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/
  GEN     /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/bpf_helper_defs.h
  MKDIR   /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/staticobjs/
  CC      /root/linux-6.1/tools/bpf/resolve_btfids/libbpf/staticobjs/libbpf.o
libbpf.c:46:10: fatal error: libelf.h: Aucun fichier ou dossier de ce type
   46 | #include <libelf.h>
      |          ^~~~~~~~~~

# => header libelf.h manquant


# solution : https://github.com/buserror/simavr/issues/170

root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# apt install -y libelf-dev
root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# make

# => OK fichier resolve_btfids compilé avec succès !

#
# Suite et fin du #20
#


root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# ls -dl /lib/modules/$(uname -r)/build/tools/bpf
ls: impossible d'accéder à '/lib/modules/6.1.0-10-amd64/build/tools/bpf': Aucun fichier ou dossier de ce type
root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# mkdir -p /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/
root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# cp resolve_btfids /lib/modules/$(uname -r)/build/tools/bpf/resolve_btfids/


#
# Retour à la compilation du module
#


root@vm-bookworm:~/linux-6.1/tools/bpf/resolve_btfids# cd ~/ms912x-main

root@vm-bookworm:~/ms912x-main# make clean

root@vm-bookworm:~/ms912x-main# make
...
Skipping BTF generation for /root/ms912x-main/ms912x.ko due to unavailability of vmlinux
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »

# => idem : même erreur !


# solution : https://devicetests.com/fixing-skipping-btf-generation-error-ubuntu-kernel-module-build

root@vm-bookworm:~/ms912x-main# apt install -y dwarves

root@vm-bookworm:~/ms912x-main# ls -ld /sys/kernel/btf
drwxr-xr-x 2 root root 0 13 sept. 17:58 /sys/kernel/btf

root@vm-bookworm:~/ms912x-main# ls -ld /usr/lib/modules/$(uname -r)/build
lrwxrwxrwx 1 root root 37 14 juil. 05:46 /usr/lib/modules/6.1.0-10-amd64/build -> /usr/src/linux-headers-6.1.0-10-amd64

root@vm-bookworm:~/ms912x-main# cp -a /sys/kernel/btf/vmlinux /usr/lib/modules/6.1.0-10-amd64/build/

root@vm-bookworm:~/ms912x-main# make clean

root@vm-bookworm:~/ms912x-main# make
make CHECK="/usr/bin/sparse" -C /lib/modules/6.1.0-10-amd64/build M=/root/ms912x-main modules
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »
  CC [M]  /root/ms912x-main/ms912x_registers.o
  CC [M]  /root/ms912x-main/ms912x_connector.o
  CC [M]  /root/ms912x-main/ms912x_transfer.o
  CC [M]  /root/ms912x-main/ms912x_drv.o
  LD [M]  /root/ms912x-main/ms912x.o
  MODPOST /root/ms912x-main/Module.symvers
  CC [M]  /root/ms912x-main/ms912x.mod.o
  LD [M]  /root/ms912x-main/ms912x.ko
  BTF [M] /root/ms912x-main/ms912x.ko
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.1.0-10-amd64 »

# => OK pas d'avertissement de vmlinux

Charger le module

root@vm-bookworm:~/ms912x-main# insmod /root/ms912x-main/ms912x.ko
insmod: ERROR: could not insert module /root/ms912x-main/ms912x.ko: Unknown symbol in module

root@vm-bookworm:~/ms912x-main# lsmod | grep -c ms912x
0

root@vm-bookworm:~/ms912x-main# journalctl -k | grep ms912x
sept. 09 01:00:53 vm-bookworm kernel: ms912x: loading out-of-tree module taints kernel.
sept. 09 01:00:53 vm-bookworm kernel: ms912x: module verification failed: signature and/or required key missing - tainting kernel
...
sept. 09 02:26:57 vm-bookworm kernel: ms912x: Unknown symbol drm_gem_shmem_dumb_create (err -2)
sept. 09 02:26:57 vm-bookworm kernel: ms912x: Unknown symbol drm_gem_shmem_prime_import_sg_table (err -2)
...

# => symbols drm_gem_shmem_*


# Attention : `make clean` supprime le module sm912x.ko (on doit le construire à nouveau)

root@vm-bookworm:~/ms912x-main# make clean

#
# Investigations personnelles sur le problème
#

root@vm-bookworm:~/ms912x-main# grep -Eirl "drm_gem_shmem_dumb_create|drm_gem_shmem_helper.h" /usr/src/linux-headers-6.1.0-10-common/
/usr/src/linux-headers-6.1.0-10-common/include/drm/drm_gem_shmem_helper.h

# => ces symboles proviennent du header drm_gem_shmem_helper.h


root@vm-bookworm:~/ms912x-main# grep -Eirl drm_gem_shmem_helper.h /usr/src/linux-headers-6.1.0-10-common/
/usr/src/linux-headers-6.1.0-10-common/include/drm/drm_gem_shmem_helper.h

# => ... qui n'est pas le header d'un autre code ...


root@vm-bookworm:~/ms912x-main# grep -Eirl drm_gem_shmem_helper.h .
./ms912x_drv.c

# => ... mais cet header est pourtant utilisé dans le projet !

Les questions

Comment finaliser ? Pourquoi les symboles ne sont-ils pas exportés ?

=> j'ai trouvé ça mais je n'ai pas compris si et comment ça pouvait résoudre le problème

Est-ce donc nécessaire de traiter le problème vmlinux ou peut-on l'ignorer vu que c'était un avertissement ?

Les fichiers module résultants avec la solution de mamiemando et [Dal] sont différents (testé avec diff), aussi selon si on traite le problème  vmlinux ou PAS, le résultat sera aussi différent, enfin appliquer rigoureusement la même procédure donne des fichiers identiques. Pourquoi ces comportements ? Est ce que les références aux headers sont figés en dur (statiques) dans les modules ?

Le mot de la fin

J'espère ne pas vous avoir trop assommé avec tous ces écrits mais j'y ai passé beaucoup de temp. Comme j'ai des troubles de l'attention j'ai du mal à être rigoureux, j'oublie vite un truc, donc suis obligé de refaire ce que j'ai déjà fait. C'est pour ça que j'essaye d'avoir un canevas près à l'emploi sur un peu tout et que je détaille ma démarche en "pas à pas" et puis aussi j'aime beaucoup partager mes découvertes ;) !

Par ailleurs quand ce sera possible je publierais la ou les solutions sur un espace un peu plus dédié à ça que sur ce forum.

Bonne nuit :) !

Avec adelphité,

lnj

Si tu envisages de proposer tes modifications dans un pull request GitHub, ce serait sans doute d'ailleurs le mieux, car il n'y a pas vraiment de raison de déporter ces considérations en dehors de "ms912x.h". Le seul intérêt de garder la séparation, c'est de séparer toutes nos corrections du code existant plutôt que charcuter à droite à gauche le code.

Je reviendrais sur ce point qui m'intéresse beaucoup ... ;)

Les deux solutions sont équivalentes, mais différentes dans leur réalisation.

Ma question portait sur le fait que les 2 binaires résultants ne soient pas identiques (diff) en utilisant le même kernel, alors que dans ma logique ils le devraient.

Concrètement, cela oblige à créer une paire clé, l'enregistrer dans le BIOS (enroll), et l'utiliser pour signer le module (sign), puis redémarrer. J'ai détaillé toute la démarche dans ce tutoriel (voir section "Création de la paire de clés" et "Signature du module").

J'avais un doute sur le type de BIOS que j'utilisais (source) en tout cas en virtu ça donne :

root@vm-bookworm:~# \
[ -d /sys/firmware/efi ] && echo BIOS UEFI || echo BIOS Legacy
BIOS Legacy

De manière générale, je boote mes systèmes (physiques et virtuels) en BIOS legacy et NON en BIOS EFI or MOK c'est pour EFI il me semble.

Comme je n'ai pas encore trouvé comment signer le module, j'ai voulu contourner en désactivant la vérification de signatures pour voir si le module se chargerait au final mais dans mon cas ça n'a pas fonctionné (pourtant ici ça a l'air d'avoir fonctionné).

A suivre ...

Bonjour,

Ma question portait sur le fait que les 2 binaires résultants ne soient pas identiques (diff) en utilisant le même kernel, alors que dans ma logique ils le devraient.

Je ne sais pas. Pour faire la comparaison, tu devrais plutôt regarder le résultat du préprocesseur (ce que j'ai appelé plus haut la précompilation) avec gcc -E pour n'exécuter que le préprocesseur. Ainsi tu n'auras que du code source à comparer.

De manière générale, je boote mes systèmes (physiques et virtuels) en BIOS legacy et NON en BIOS EFI or MOK c'est pour EFI il me semble.

Effectivement, en BIOS legacy, tu n'as pas à te soucier de signer ton module. Le secure boot est une fonctionnalité propre a l'UEFI. Lorsqu'il est activé et que le noyau Linux a été compilé "normalement", le secure boot oblige à signer les modules compilés par soi-même, sans quoi le noyau Linux refuse (en général) de les charger. 

Comme je n'ai pas encore trouvé comment signer le module, j'ai voulu contourner en désactivant la vérification de signatures pour voir si le module se chargerait au final mais dans mon cas ça n'a pas fonctionné (pourtant ici ça a l'air d'avoir fonctionné).

Pour commencer, vu que tu es en BIOS legacy, tu n'as normalement pas à te préoccuper de signer ton module.

Dans le cas contraire, la signature d'un module est détaillée dans le tutoriel sur le pilote nvidia que je t'ai déjà indiqué (le section "le module n'est pas signé"). Ce qui y est raconté n'est pas propre à nvidia, mais à tout module compilé à la main ou par DKMS. Une fois la clé crée, le script proposé se charge de signer tous les modules concernés, qui pourront alors être chargé une fois que tu auras enrôlé la clé.

Dans les liens que tu proposes, que je n'ai jamais testé, il est question de l'option CONFIG_MODULE_SIG. D'après ce qui est expliqué ici, c'est une option de compilation du noyau (donc rien à voir avec le module que tu es en train de compilé).

• Par défaut, cette variable vaut "y" et le noyau engendré refusera si le secure boot est activé de charger un module DKMS ou compilé à la main non signé. C'est typiquement le choix qui est fait sur un noyau standard (tel que celui déployé par linux-image-amd64, le choix a donc déjà été fait).
• La passer à "n" permet de ne plus avoir à signer les modules compilés à la main ou via DKMS, mais rendent par la même occasion ton noyau plus vulnérable. Bref, c'est un "contournement" pas hyper élégant et pas très propre. Mieux vaut créer sa clé et signer ses modules proprement.

Bonne chance