A preliminary study on Linux Drive model 2--device_driver
1, thinkingDevice_driver is also a kobject? , but you notice no, in the sys/directory has bus/, there is device/is no device_driver/,y? Why is it so designed?
first look at the struct devic_driver;
struct Device_driver {Const char *name;struct Bus_type *bus;...Int (*probe) (struct device *dev);Int (*remove) (struct device *dev);void (*shutdown) (struct device *dev);Int (*suspend) (struct device *dev, pm_message_t state);Int (*resume) (struct device *dev);...const struct Dev_pm_ops *pm;struct driver_private *p;};Although there is no kobject in the device_driver, there are kobject among his driver_private members,struct Driver_private {struct kobject kobj;...};but how to prove that he uses this private data kobj to interact with other KOJB, see Driver_register (),bus_add_driver(struct device_driver *drv) Is "Connected" by Kobject/kset and bus. Kobject_init_and _add(&priv->kobj, &driver_ktype, NULL, "%s", drv->name); Kobject's add is also through Priv->kobj. It is recommended that Bus_add_driver be remembered and used later. OK, the first question answered, then the second question? In fact, as in the first answer, in the Bus_add_driver function. First look at the invocation relationship:int driver_register (struct device_driver *drv) -Bus_add_driver(struct device_driver *drv) -Priv->kobj.kset = bus->p->drivers_kset; kobject_init_and_add(&priv->kobj, &driver_ktype, NULL, "%s", drv->name); -Kobject_add_varg (kobj, parent, FMT, args); -kobject_add_internal (kobj); -/ * Join Kset If set, use it as parent if we don't already have one */if (kobj->kset) {if (!parent)parent = Kobject_get (&kobj->kset->kobj);Kobj_kset_join (kobj);kobj->parent = parent;}The answer should be this code. Because Kobj->kset is already assigned, the kobj->parent at this time is bus->p->drivers_kset. Therefore, the new driver will be in the bus in the driver file, not/sys/under a drivers folder. The third question, why is this design? temporarily not figured out, the architectural level of things can rise to a philosophical view. I look forward to a philosopher's advice, or Zhou Gong dreams.
2,driver_register (struct device_driver *drv)before reading the register function, look at a class diagram of the struct device_driver (only key members are listed)
look Again, driver_register (), I highlight a few key functions .int driver_register (struct device_driver *drv){int ret;struct device_driver *other;
bug_on (!drv->bus->p);
if ((drv->bus->probe && drv->probe) | |(drv->bus->remove && drv->remove) | |(Drv->bus->shutdown && drv->shutdown))PRINTK (kern_warning "Driver '%s ' needs updating-please use""Bus_type methods\n", drv->name);
Other = Driver_find (Drv->name, drv->bus);if (other) {PRINTK (kern_err "Error:driver '%s ' is already registered,""aborting...\n", drv->name);return-ebusy;}
ret = bus_add_driver(DRV);if (ret)return ret;ret = driver_add_groups(DRV, drv->groups);if (ret) {Bus_remove_driver (DRV);return ret;} kobject_uevent(&drv->p->kobj, kobj_add);
return ret;}
The core function of this function is Bus_add_driver, which is basically analyzed in the previous, he is in the specified bus (busy_type type) Drivers folder to add their own, the internal logic is added to the Bus->p->klist_ Drivers in the linked list. by the way, if the switch is judgedif ((drv->bus->probe && drv->probe) | | (Drv->bus->remove && drv->remove) | | (Drv->bus->shutdown && Drv->shutdown)) If both DRV and Drv->bus implement the Probe/remove/shutdown method, a warning is printed. See the class diagram above can also see there are two probe, from the warning information, if the bus implements the probe function, the bus is used. But we know that the bus can hang a lot of driver, the actual operation should not realize the bus probe, and is left to the corresponding driver to achieve. So what's the relationship between the two probe? See a diagram (Come to the Netizen tynew) if all is implemented, this error will be printed
Look againdriver_add_groupsfunction is to add **groups in the driver structure to the SYS file system (see above class diagram)
Look againkobject_uevent(&drv->p->kobj, kobj_add);The function is the event that handles Kobj_add, which invokesCall_usermodehelper (argv[0], argv,ENV->ENVP, umh_wait_exec); Start a user program. This is the function of uevent.
the realization of 3,kf_driver
code: (see GitHub Project for full version)
static int kf_device_driver_probe (struct device *dev) {PRINTK ("Enter drive probe\n");return 0;}static struct Device_driver kf_device_driver={. Name = "Kf-device-driver",. Probe = Kf_device_driver_probe,};static int kf_device_dirver_register (void) {int ret =-1;Kf_device_driver.bus = &kf_bus_type;//Specify which bus (bus_type) to hang onret = Driver_register (&kf_device_driver);printk ("Kf_device_driver reister ok!\n");return ret;}static void Kf_device_dirver_unregister (void) {Driver_unregister (&kf_device_driver);}
compiled into KO, on the platform, insod up, let's take a look at the SYS file system. added some files in the/sys/bus/kf-bus/driver
Kf-device-driver is the name of our newly added dirver.Driver_register ()->bus_add_driver ()->kobject_init_and_add (&priv->kobj, &driver_ktype, NULL, "%s", drv->name);
->...->kobject_add_internal (kobj); generating kf-device-dirver What about the bind uevent unbind?
uevent:Driver_register ()->bus_add_driver (),driver_create_file(DRV, &driver_attr_uevent);
Bind,unbind
Driver_register ()->bus_add_driver ()->add_bind_files (DRV);-Driver_create_file(DRV, &driver_attr_unbind); Driver_create_file (DRV, &driver_attr_bind);
//uevent, as well as the kernel notification chain (Blocking_notifier_call_chain (&dev->bus->p->bus_notifier,bus_notify_bound_driver, Dev); need to open a new story
driver also has a very important function.__driver_attach. He and the bus __device_attach the same way, see how they are together? Look at the diagram above.
A preliminary study on Linux Drive model 2--device_driver
