Journal Porter un driver sur un 2.6

Posté par  (site web personnel) .
Étiquettes :
0
19
avr.
2004
Bonjour à tous !!

Pour ceux qui suivent, ce journal fait suite à un autre demandant le soutien de personnes pour développer un driver.

Finalement, ce driver existait déja, et on peut d'ailleurs le trouver sur
http://www.emota.com.br/wireless/extra/Am1771.tar.bz2(...)

Ma première question est qu'en pensez vous? Il me semble plutôt étrange, et pas forcément open source, et un pdf contenu dans le fichier possède comme entête AMD Confidential, ce qui tenderais à prouver que ce driver a été en quelque sorte "dérobé" au gentils gars d'AMD, qui font des gentils drivers pour linux.

Bref, la question n'est pas là, le driver date de Aout 2003 et est en conséquence pas du tout compatible 2.6, ce qui crée mon désarroi pour une utilisation de tous les jours (pire que rebooter pour jouer sous windows, rebooter sur un 2.4 pour utiliser ma carte wifi... ;-)

Donc, auriez-vous un site, ou encore mieux des conseils permettant de passer simplement un driver en 2.6, à la condition que le driver mentionné au dessus soit GPL, car on va pas se faire du mal avec des trucs illégaux...

Je suis bien tomber sur lwn.net, mais les explications ne sont pas assez étoffés à mon goût, et il n'expliquerait pas, juste par exemple, pourquoi (attention, passage effrayant), entre le 2.4 et le 2.6

la structure pci_dev à perdu un champ void* driver_data, sans raison apparente, et SURTOUT, comment réussir à ce séparer de ce champ (un peu trop utilisé à mon goût dans ce driver)


Merci.

  • # Re: Porter un driver sur un 2.6

    Posté par  . Évalué à 2.

    J'ai pas lu toute les sources (immenses comme archive)
    mais un drivers 2.4 recent et bien ecris ce porte facilement sur un 2.6.
    Quand tu le compile tu as quoi d'autre comme message d'erreur ?
    La structure pci_dev->driver_data etait une zone de stockage que le driver utilisait pour ces donnes a lui et a ca sauce.
    en general on faisait un kmalloc d'une structure et l'adresse de resultat etait mémorisée dans pci_dev->driver_data.
    Pour s'en debarasser remplace toute les references vers une variable globale de la structure en question.
    Quand au modification du driver, si on te donnne les sources , que tu les modifie et ne les redistribue pas ca m'etonnerait que tu ai des soucis legaux.

    • [^] # Re: Porter un driver sur un 2.6

      Posté par  (site web personnel) . Évalué à 1.

      Comme autre message d'erreur, il s'est arrêté au fait que driver_data n'existe plus, et cela se fait au niveau du fichier Linux/Khal/Kpci/Kpci.c.

      Mais cela passe par des macros, alors pour transformer cela, c'est pas forcément gagné.

      merci d'aider, je te plussoie!

      Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

    • [^] # Re: Porter un driver sur un 2.6

      Posté par  (site web personnel) . Évalué à 1.

      Bon, en fait, cela a bien fonctionné, mais l'appel à driver_data est fait dans plusieurs fichiers, alors comment et ou placer la dite variable globale?

      Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

  • # Re: Porter un driver sur un 2.6

    Posté par  (site web personnel) . Évalué à 1.

    Bon, en commentant les erreurs, il n'y en a que 4
    J'ai réussit a me dépatouiller pour le driver_data, merci, mais maintenant, problème suivant, cette fois ci c'est du C :

    On a cette structure et cette définition de type :


    
typedef struct _khal_dev
    
{
    
    /* general khal globals                                                 */
    
    hw_if_supp_t     dev_type;          /* supported hw_i/f for this device */
    

    
...
    

    
    /* spinlock for khal_blktra_put_mac_indication() via interrupt buffer   */
    
    spinlock_t          blktra_spinlock;
    

    
...
    

    

    
    UINT8             interrupt_node_name[MAX_INTERRUPT_NODE_STRING];
    
                                            /* unique identifer for PCI     */
    
                                            /* interrupt node used in       */
    
                                            /* /proc/interrupts             */
    

    
} khal_dev_t, *pKhal_dev_t, **ppKhal_dev_t;


    On a cette fonction qui utilise la structure ci-dessus :


    
oswr_success_t  khal_create_instance(ppKhal_dev_t ppKhal_dev)
    
{
    
    
    
    oswr_success_t result = OSWR_UNSUCCESSFUL;
    

    
    OSWR_DPF(("===> khal_create_instance\n"));
    

    
    *ppKhal_dev = (pKhal_dev_t) kmalloc(sizeof(khal_dev_t), GFP_KERNEL);
    

    
    if (*ppKhal_dev != NULL)
    
    {
    
        /* initialization of data	                                        */
    
        memset(*ppKhal_dev, 0, sizeof(khal_dev_t));
    
        spin_lock_init(&(*ppKhal_dev->blktra_spinlock));
    
        result = OSWR_SUCCESSFUL;
    
    }
    

    
    OSWR_DPF(("<=== khal_create_instance\n"));
    

    
    return (result);
    
}


    Et on a ce message d'erreur à la compilation :

    gcc -DCONFIG_KMOD -DEXPORT_SYMTAB -DMODULE -D__KERNEL__ -DLINUX -DCONFIG_PROC_FS -I/home/lastnico/Am1771/Linux/../Include -I/usr/src/linux/include -Wall -DNAUTILUS_CFG_PLATF_X86 -DNAUTILUS_CFG_PCI -DNAUTILUS_SYSTEM_IS_MAC_SME_TARGET -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=`uname -m` -malign-functions=4 -fno-omit-frame-pointer -Os -I/home/lastnico/Am1771/Linux/../Include -I/usr/src/linux/include -IInclude -I../Include -c -o obj/x86/2.6.1/Khal.o "Khal.c"
    cc1: warning: -malign-functions is obsolete, use -falign-functions
    Khal.c: In function `khal_create_instance':
    Khal.c:641: error: request for member `blktra_spinlock' in something not a structure or union
    make[1]: *** [obj/x86/2.6.1/Khal.o] Erreur 1



    A votre avis, quel est la solution ?

    Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

    • [^] # Re: Porter un driver sur un 2.6

      Posté par  . Évalué à 1.

      sans doute un probleme de priorité d'operateur
      au lieu de
      spin_lock_init(&(*ppKhal_dev->blktra_spinlock));
      essaie
      spin_lock_init(&( (*ppKhal_dev)->blktra_spinlock));

      • [^] # Re: Porter un driver sur un 2.6

        Posté par  (site web personnel) . Évalué à 1.

        oui, c'est effectivement ce que j'ai trouvé après coup, merci de me confirmer, j'en ai besoin, car je nage un peu dans ce boxon de sources ( et c'est en plus ma première correction de driver, ca promet...)

        Ah oui, est-il possible de casser du matos avec un driver miteux??

        Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

        • [^] # Re: Porter un driver sur un 2.6

          Posté par  . Évalué à 1.

          oui...mais c'est rare et cela signifie en general que le hardware est concu bancalement.
          ce qui m'etonnerait de la part d'amd a vrai dire

  • # Re: Porter un driver sur un 2.6

    Posté par  (site web personnel) . Évalué à 1.

    Allez dernière question et je tente de crasher mon linux avec mon driver tout moche, mais qui passe la compilation avec un 2.6

    Une ligne

    spin_unlock_irg(&current->sigmask_lock);

    ne passe pas la compilation, et me dit que current ne possède pas d'attribut sigmask_lock.

    Le problème dans tout ca, c'est que current est une variable introuvable, dnas le sens ou elle est défini nul part dans le code, et je ne peut pas savoir si sigmask_lock est réellement contenu dans l'éventuel structure représenté par la variable current.

    Est-ce une variable par défaut, ou j'ai mal cherché?

    Merci.

    PS: Cette variable se retrouve un peu partout dans le fichier Linux/Kthread/Kthread.c pour les précisions...

    Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

  • # Re: Porter un driver sur un 2.6

    Posté par  (site web personnel) . Évalué à 1.

    Aaaaaarrgghh,

    En faisant un insmod Nautilus.o

    Il me dit :

    insmod: error inserting 'Nautilus.o': -1 Invalid module format

    Que faireeuuhh!!!

    Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

    • [^] # Re: Porter un driver sur un 2.6

      Posté par  . Évalué à 1.

      avec le 2.6 le fichier de sortie n'est plus un .o mais un .ko si ma memoire est bonne.

    • [^] # Re: Porter un driver sur un 2.6

      Posté par  . Évalué à 1.

      Extrait de ce qu'il te faut suivre ABSOLUMENT pour remettre
      a la norme ton module qui viens du 2.4.xx
      doc consultable en ligne a:
      http://www-106.ibm.com/developerworks/linux/library/l-inside.html(...)

      Driver porting to Linux 2.6
      The 2.6 kernel has brought along with it a pretty significant list of changes for driver developers. This section highlights some of the important aspects of device driver porting from the 2.4 to 2.6 kernel.

      First, the kernel build system has been improved for quicker builds compared with 2.4. Improved graphical tools have been added: make xconfig (requires Qt libraries) and make gconfig (requiring GTK libraries).

      The following are some of the highlights of the 2.6 build system:

      Creates arch-zImage and modules by default when just make is issued
      For parallel make, make -jN is the preferred choice
      make is not verbose by default (set KBUILD_VERBOSE=1 or use make V=1 to change this)
      make subdir/ will compile all the files within subdir/ and below
      make help will provide the make targets supported
      make dep need not be run at any stage
      The kernel module loader has also been completely reimplemented in 2.5, which means that the module-building mechanism is much different compared to 2.4. A new set of module utilities is needed for module loading and unloading (please see Resources for a download link for those). Old 2.4 makefiles will no longer work as of 2.6.

      The new kernel module loader is the work of Rusty Russel. It makes use of the kernel build mechanism and produces a .ko (kernel object) module object instead of an .o module object. The kernel build system compiles the module first and then links to vermagic.o. This creates a special section in the object module that contains information like the compiler version used, the kernel version, whether kernel preemption is used, and so on.

      Now let's take an example and analyze how the new kernel build system should be used to compile and load a simple module. The module concerned is a "hello world" module and is similar to 2.4 module code except that module_init and module_exit need to be used instead of init_module and cleanup_module (kernel 2.4.10 modules onwards use this mechanism). The module is named hello.c and the Makefile is as follows:

      Listing 3. Example driver makefile

      KERNEL_SRC = /usr/src/linux
      SUBDIR = $(KERNEL_SRC)/drivers/char/hello/
      all: modules

      obj-m := module.o
      hello-objs := hello.o

      EXTRA_FLAGS += -DDEBUG=1

      modules:
      $(MAKE) -C $(KERNEL_SRC) SUBDIR=$(SUBDIR) modules



      This makefile uses the kernel build mechanism to build the module. The compiled module will be named module.ko and is obtained by compiling hello.c and linking with vermagic. KERNEL_SRC indicates the kernel source directory and SUBDIR indicates the directory where the module is located. EXTRA_FLAGS indicate any compile-time flags that need to be given.

      Once the new module (module.ko) is created, it can be loaded and unloaded by using the new module utilities. Older module utilities used in 2.4 cannot be used for loading and unloading the 2.6 kernel modules. The new module loading utility tries to minimize the occurrence of race conditions that may occur when a device is opened while the corresponding module is being unloaded, but after the module has made sure that no one is using it. One of the reasons for these race conditions is that the module usage count is manipulated within the module code itself (via MOD_DEC/INC_USE_COUNT).

      In 2.6, the module need not do this step of increasing/decreasing the reference count. Instead, this is now done outside of module code. Any code that tries to reference the module has to call try_module_get(&module), and upon success can access the module; this call will fail if the module is being unloaded. Correspondingly, references to the module can be released by using module_put().

  • # As-tu reussi?

    Posté par  . Évalué à 1.

    Salut,

    Aurais-tu reussi ton port?
    J'ai acheté cette carte trop rapidement, alors si tu as reussi et que tu peux m'envoyer les sources modifiees je serais un homme comblé.

    merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.