Pourquoi la méthode probe est-elle nécessaire dans les pilotes de périphériques Linux en plus de init ?

Question

Dans le noyau linux, que fait l'élément probe() que le conducteur fournit, font ? En quoi est-elle différente de la méthode du conducteur init c'est-à-dire pourquoi la fonction probe() Les actions des fonctions sont effectuées dans le poste de conduite init fonction ?

Answer 1

Différents types de périphériques peuvent avoir des fonctions probe(). Par exemple, les périphériques PCI et USB ont tous deux des fonctions probe().

Si vous parlez de périphériques PCI, je vous recommande de lire le chapitre 12 de Pilotes de périphériques Linux qui couvre cette partie de l'initialisation du pilote. La question de l'USB est traitée au chapitre 13.

Réponse plus courte, en supposant que le PCI : La fonction init du pilote appelle pci_register_driver() qui donne au noyau une liste des périphériques qu'il est en mesure de prendre en charge, ainsi qu'un pointeur sur le fichier probe() fonction. Le noyau appelle ensuite la fonction probe() une fois pour chaque appareil.

Cette fonction de sonde démarre l'initialisation par périphérique : initialisation du matériel, allocation des ressources et enregistrement du périphérique auprès du noyau en tant que bloc ou périphérique réseau ou autre.

Cela facilite la tâche des pilotes de périphériques, car ils n'ont jamais besoin de rechercher des périphériques ou de s'inquiéter de retrouver un périphérique branché à chaud. Le noyau s'occupe de cette partie et notifie le bon pilote lorsqu'il a un périphérique à gérer.

Answer 2

@Bandicoot Si le périphérique n'est pas connectable à chaud, la fonctionnalité de probe() peut être placée dans la méthode init(), ce qui réduira l'empreinte mémoire du pilote au moment de l'exécution. P.S lien

Pour un périphérique "plate-forme", la fonction probe est invoquée lorsqu'un périphérique plate-forme est enregistré et que son nom correspond au nom spécifié dans le pilote du périphérique. P.S lien

La fonction i2c_detect sonde l'adaptateur I2C, à la recherche des différentes adresses spécifiées dans la structure addr_data. Si un périphérique est trouvé, la fonction chip_detect est alors appelée. P.S lien .

Un lien qui va sûrement lever vos doutes. P.S lien

Dans le noyau 2.4.29, je peux vous montrer comment la sonde se produit ? Veuillez voir ci-dessous (Nom du fichier : drivers/acorn/char/pcf8583.c )

static struct i2c_driver pcf8583_driver = {
name:       "PCF8583",
id:     I2C_DRIVERID_PCF8583,
flags:      I2C_DF_NOTIFY,
attach_adapter: pcf8583_probe, /* This will be called from i2c-core.c P.S see below function i2c_add_driver()*/
detach_client:  pcf8583_detach,
command:    pcf8583_command

} ;

Nom du fichier : drivers/i2c/i2c-core.c

int i2c_add_driver(struct i2c_driver *driver)
{
    ........................
    ........................

    /* now look for instances of driver on our adapters
     */
    if (driver->flags& (I2C_DF_NOTIFY|I2C_DF_DUMMY)) {
        for (i=0;i<I2C_ADAP_MAX;i++)
            if (adapters[i]!=NULL)
                /* Ignore errors */
                driver->attach_adapter(adapters[i]); /*This is a location from where probe is called. Pointer **driver** is of type **pcf8583_driver** which you have passed into this function*/
    }
    ADAP_UNLOCK();
    return 0;
}

Quelques liens importants :

1) http://www.slideshare.net/varunmahajan06/i2c-subsystem-in-linux2624

2) http://www.programering.com/a/MjNwcTMwATM.html

3) http://www.linuxjournal.com/article/6717

4) http://www.developermemo.com/2943157/

5) http://free-electrons.com/doc/kernel-architecture.pdf

6) http://www.techques.com/question/1-3014627/Probe-problem-when-writing-a-I2C-device-driver

Dans le PCI pour kernel-2.4.29, il est appelé lorsque le vendeur et l'identifiant du périphérique sont identifiés. Le pilote du bus PCI le fait pour vous. Veuillez voir le code ci-dessous :

Nom du fichier : drivers/pci/pci.c

static int pci_announce_device(struct pci_driver *drv, struct pci_dev *dev)
{
   const struct pci_device_id *id;
   int ret = 0;
   if (drv->id_table) {
    id = pci_match_device(drv->id_table, dev); /* check for device presence*/
    if (!id) {
     ret = 0;
     goto out;
    }
   } else
  id = NULL;
  dev_probe_lock();
  if (drv->probe(dev, id) >= 0) { /* This is a location from where probe is called*/
   dev->driver = drv;
   ret = 1;
   }
   dev_probe_unlock();
  out:
  return ret;
}

Answer 3

Init(void) // s'exécute une fois lorsque le pilote/module est invoqué et met les choses en place pour la machine pilote du noyau.

Probe(*pdev) // est utilisé par la machine pilote du noyau selon les besoins pour détecter et installer les périphériques réels.

Answer 4

Les conducteurs xxx_init_module() appels de fonction pci_register_driver(struct pci_driver *drv) en passant la référence à une structure de type pci_driver . struct pci_driver est une structure importante que tous les pilotes PCI devraient avoir, qui est initialisée avec des variables comme le nom du pilote, la liste des périphériques PCI que le pilote peut supporter, les routines de rappel pour le sous-système central PCI.

La structure pci_driver des pilotes comporte des champs de membres importants énumérés ci-dessous :

1. name - Nom du pilote qui est unique parmi tous les pilotes PCI du noyau. Il apparaîtra sous /sys/bus/pci/drivers .

2. pci_device_id - Un tableau de données d'identification des périphériques comprend le type de puces que ce pilote prend en charge.

3. probe - L'adresse de xxx_probe() fonction.

4. remove/suspend/resume/shutdown - Adresse de la fonction que le système central PCI appelle lorsque le dispositif PCI est retiré/suspendu/repris/arrêté respectivement. Généralement utilisé par les couches supérieures pour la gestion de l'énergie.

Pour plus d'informations sur la façon dont le sondage du pilote exécuté à partir du noyau PCI se référer à Init du pilote de périphérique Linux .

Answer 5

Dispositifs multiples et hotplug

1. Vous exécutez un grand serveur avec de nombreux accélérateurs GPUs connectés à des PICe. À un moment donné, vous décidez d'acheter plus de GPU pour les emplacements libres.

   Si nous avons utilisé init alors nous devrions rmmod y insmod le module. Mais cela nécessiterait d'arrêter tous les GPU connectés, ce qui entraîne des temps d'arrêt.

   Avec probe on branche juste les nouveaux GPU et on fait un rescan.

2. Le hotplug PCIe ne serait pas possible autrement : https://electronics.stackexchange.com/questions/208767/does-pcie-hotplug-actually-work-in-practice

Exemple de périphérique QEMU edu PCI

QEMU dispose d'un dispositif PCI éducatif appelé edu, qui nous permet de tester facilement quand probe s'appelle.

D'abord, nous avons besoin d'un pilote PCI minimal pour le noyau Linux, que j'ai écrit ici .

Nous pouvons commencer par le dispositif attaché avec :

-device edu

mais ce qui est encore plus intéressant, c'est que nous pouvons attacher et retirer le périphérique du moniteur QEMU également, Ctrl + Alt + 2 sur SDL GUI ou -monitor telnet::45454,server,nowait sur CLI, avec les commandes :

device_add edu
device_del edu

Si le périphérique est attaché au démarrage :

• probe est appelé dès que nous insmod le module

• dmesg contient une ligne de caractères : pci 0000:00:04: [1234:11e8] ... qui montre que notre appareil a été sondé à BDF 0000:00:04 .

  Nous savons que c'est notre périphérique, car le vendeur est 0x1234 et l'id de périphérique 11e8 dans la source QEMU.

  Nous en concluons donc que les périphériques PCI sont sondés au démarrage, et stockés dans une liste quelque part.

Si nous attachons le dispositif après le démarrage du moniteur :

• rien ne se passe tant que nous ne le faisons pas :

  echo 1 > /sys/bus/pci/rescan

  Voir aussi : Comment peut-on forcer le noyau linux à énumérer le bus PCI-e ?

• après le rescan :

  • si nous avions déjà insmoddé, probe est appelé immédiatement.

    Donc dans ce cas, probe s'est produit séparément de insmod en montrant comment ils diffèrent.

  • si nous ne l'avons pas fait : probe est appelé immédiatement après insmod