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

Question

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

"sys/devices/virtual/wdc_per" 

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

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

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

Кто-нибудь может помочь мне узнать этот UserSpace в пространстве ядра ссылки.

Answer 1

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

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

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

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

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