Как выполняется обратный вызов из пользовательского пространства в пространство ядра

Я изучаю драйвер и просматриваю код драйвера watchdog, где какое-то значение записывается в /sys/devices/virtual/wdc_per теперь я предполагаю, что это логика того, как драйвер получает свое значение из пользовательского пространства, а открытый файл в пользовательском пространстве

  "sys/devices/virtual/wdc_per" 

Но теперь, как на самом деле это значение от wdc_per доходит до драйвера, должен поддерживаться некоторый обратный вызов

В моем случае его сторожевой драйвер GPIO и gpio_wdt.c могут иметь этот обратный вызов.

Но я действительно не мог понять, как это происходит на самом деле

Любой может помочь мне узнать это пространство для использования в пространстве ядра.

    Во-первых, этот драйвер gpio_wdt.c , похоже, не существует в ядре mainline с этой даты, поэтому его сложно комментировать.

    Sysfs (обычно установленный на /sys ) на самом деле очень прост в использовании. Это отличный пример того, как создавать атрибуты Sysfs. В принципе, вы создаете атрибуты (станут именами файлов Sysfs) и регистрируете их с помощью двух определенных операций (обратных вызовов): сохраняете и показываете , что эквивалентно соответственно. писать и читать . Обратный вызов show вызывается каждый раз, когда файл Sysfs (атрибут) считывается и сохраняется, когда он написан.

    При написании драйвера устройства, принадлежащего существующему classу (скорее всего, ваша ситуация), вам редко приходится делать это самостоятельно. Это связано с тем, что стандартные classы устройств Linux уже имеют рабочий набор атрибутов Sysfs, который ваш драйвер будет использовать более или менее косвенно.

    Например, class светодиодов (светодиодные устройства), из которых вы найдете устройства в /sys/class/leds , имеет связку атрибутов Sysfs на каждый светодиод, чтобы пользователь мог читать / изменять их из пользовательского пространства (яркость, максимальная яркость , триггер и т. д.). Теперь, если вы посмотрите на светодиодные конкретные драйверы в /drivers/leds , вы не найдете создания атрибутов Sysfs вручную. Однако вы обнаружите вызов led_classdev_register при led_classdev_register драйвера, который принимает в качестве параметра struct led_classdev* . Эта структура имеет элемент обратного вызова bright_set, который должен предоставить конкретный драйвер. Когда пользователь записывает в /sys/class/leds/whatever-led/brightness bright, вызываемый вызов classа « store» вызывает обратный вызов Sysfs, который, в свою очередь, вызывает обратный вызов ярлыка конкретного драйвера.

    Я хочу сказать: убедитесь, что вы действительно знаете свой class устройства, прежде чем вручную добавить атрибуты Sysfs. Во всяком случае, отправляя своего водителя на LKML, вы будете знать достаточно быстро, если это будет хорошим решением.