Kernel device ModelObjective: To indicate the topological relationship between equipment and equipment in the system advantages: 1 Reduce the amount of kernel code, 2 can be unified view all the device status and the connected bus, 3 can contact the device and its corresponding driver, or drive the corresponding device. 4 can be categorized by type, can be accessed along the leaf node direction to the root node to ensure proper power off of the device (first close all child nodes of the destination node, and then close the node) device model: has been abstracted through the data structure. The user's angle can be viewed from the SYS directory. Device model relationships in the kernel the first level directory that is usually opened under SYS is a different type of subsystem---------------------------------------------------------- The secondary directory is in the same type of catalog collection ----------------------------------------------------------level Three directory is the only directory look like in the kernel USB device Model For example device subsystem ----------------------------- ------------------------------USB hub-----------------------------------------------------------USB device--------------------- -------------------------------------- Kernel abstract look device subsystem ( kset x,kset a ... ) subsystem -----------------------------------------------------------USB Hub (Kobject b kobject a ... ) Kset a-----------------------------------------------------------USB Devices a kobject A----------------------------------------------------------- device abstraction features: You can differentiate the device type: character devices, access mode: Access device node, non-addressable; miscdev Simplified device driver block device, access mode: Access device node, can be addressed. (That is, the way to support the last Lseek random access) network devices, access mode: Socket API, not access device node. pseudo device, random number generator, empty device, 0 device, full device. equipment model has data structure routines: Prepare the core worker Kobject, the same type of kobject to the same workshop kset work, the kset of different workshops to integrate a subsystem. kobject and he would be a good device keeper 1kobject object to the device he was guarding. The reference counter is kept, , This object will end the work cycle if it is not referenced to this device object. The device can be removed from memory. The directory shown in 2sysfs corresponds to a Kobject, 3kobject object that has the specified paren his upper node, Forms a hierarchical relationship between different kobject, maintaining a hierarchical list in the workshop kset (the difference between the parent explanation and Kset) 4 hot-swappable kobject subsystem generation time notifies the user control kset object: Caretaker's manager &nBsp;1 Each kobject is created when the basic is assigned to their corresponding kset, so the classification will automatically find the upper layer belongs to the Kset. Speaking of this point is just to introduce you to the next level of feeling. 2 Uevent,ktype operations into the Kset subsystem subsystem: The actual is a collection of Kset and semaphores Open data structures, some doubts and introductions. Struct kobject {const char *name;//name Struct list_head entry;//as the parent object of the linked list node Struct kobject * parent;//Parent Object Struct kset *kset;//belongs to which object collection (upper Kset has a own kobject) Struct kobj_type *ktype; //Object Type struct sysfs_dirent *sd;//sysfs file system directory struct kref kref;//reference Unsigned int state_ initialized:1;//already initialized unsigned int state_in_sysfs:1;//has joined the Sysfs file system unsigned int state_add_ uevent_sent:1;unsigned int state_remove_uevent_sent:1;unsigned int uevent_suppress:1;}; struct kset { struct list_head list;// Connect all kobject of the Kset in the chain header spinlock_t list_lock; struct kobject kobj; //embedded in the kobject const struct kset_ uevent_ops *uevent_ops;//the set of operations that handle hot-swap events }; struct kobj_type {void (*release) (struct kobject *kobj);//release Kobject and other resource-occupying functions const struct sysfs_ops * sysfs_ops;//method of manipulating Properties struct attribute **default_attrs;//property array Const struct kobj_ns_type_ operations * (*child_ns_type) (struct kobject *kobj); const void * (*namespace) (struct kobject *kobj);}; 1*kset; *ktype; since Kset is a collection of the same type of kobject, why would you say that ktype the same kobject might appear in different kset? kobject after the creation of the designated Kset of their own, these found Kset kobject of the object will be its own Kobj_type type members The Ktype is replaced with the object type of the target kset. Kset with their own attributes to all to recognize their own kobject have been brushed, leading us to say that Kset is the same type of look at the object of the collection. two ktype different kobject can exist in different kset. As long as they are not assigned the same kset. due to the high priority of the kset, resulting in the classification, according to the kobject corresponding to the kobject to divide, if the creation of a good KOBject does not specify kset that would appear to be specified in Ktype. 2 says both Kset and parent are used to support the hierarchy of device models. What is the relationship between the two? Kset is the same processing object aggregation and collection as the Ktype type. The corresponding kset, parent in the underlying kobject kset to the upper layer is used to locate the Kobject object in the Sysfs hierarchy, and the parent points to the kobject in the upper layer, representing the previous node. Contact: a. The default kset is the parent of the kobject under it. before Kobject joins the linked list to the Kset collection, checks to see if the Kobject has a parent, and if it does not, it cannot find the SYSFS in Kobject, So this kobject parent directly points to the Kobjectparent = kobject_get (&kobj->kset->kobj) of the specified Kset layer; The Kset of b.kobject (also including kset) may be empty drivers such as/sys/bus/platform Kset and Devices kset, although in user space it appears platform as Kset contains driver and device, actually is not. The parent of Kobject (also including kset) may be empty (tree top node) The parent of kobjectd does not necessarily contain his kset 3 Kobject related to Kobjectkobject is used to control access to large domain objects, which are usually contained by other structs. Work 1: Used to get structure entry, character device Cdev has kobject members, often see use container_of (kp,strcut cdev, kobj); Macro definition to find the starting address of the CDEV structure. There is a formula: absolute address-relative to the address of the starting point of the struct, get the starting address of the struct body. #define container_oF (ptr, type, member) ({ \ const typeof (((type *) 0) Member) * __mptr = (PTR); \ PTR is an in-memory pointer to the member member Hlist_head absolute address (type *) ((char *) __mptr - offsetof (Type, member)); }) The node of the hlist_head list, minus the node position that has been obtained, move forward offsetof a position to get work 2: Create Kobject, keep the reference counter. A.kobject initialization is to use menmset to set the Kobject reference count Kref to 0, and then use Kobject_init () to set the reference count to 1,b. kobject_set_ Name () set a good name in the SYSFS directory display C. Add a reference to Kobject/minus reference to note the return value, Kobject_get () kobject_put () Create Kobject_add () + kobject_ Init () =kobject_register Delete kobject_del + kobject_put = kobject_unregister Create a reference to Cdev or final call to module owner in KOBJECT  the reference. Failure is to release a notification that the reference count Module_put (owner) d is not cited as 0. Kobject's kref is 0 o'clock no one knows how the Kobject has been, so to change 0 before the first asynchronous notify everyone, with Contariner to get the class object containing Kobject, then Kfree (object) When there is a reference, it cannot be released because unsafe, references are not released or released. 4kset and Ktype related a.kset Manager A list to join Kobject members, Initializes the Kset in Kobject to the upper-level target kset b. Manages the reference count of Kset kset_get () Kset_put increase and decrease the reference count of Kset from Kobject, The principle of managing references is basic and kobject consistent c.kset has a name, in addition Kset Ktype members are actually used members, That is, the type of kset that was previously said to cover the underlying type of the ktyped. destructor-related functions Ktype is the real caretaker, equipment, how to deal with all is ktype in the care of, the equipment common operation from the Kobject separated out. release: Kobject's Ktype is fixed. Release function pointer sysfs_ops:{(*show) (*kobj,*attr,*buffer) (*store) (*kobj,* Attr,*buffer,size)} Two action function user Read Property, call show to encode the specified value and place it into the buffer, returning the actual length as the return value. Or all Kobject properties use the same showstore to decode the data stored in the buffer and return the actual decoded bytes, the property has write permission to call the store to take note of the data before the legal input attribute **default_ attrs the last element must be populated with 0. Describes what properties are available. The sysfs_ops in this kobj_type provides a way to implement the properties in attribute this attribute has the *name property name in Sysfs name, Module *owneR pointer to module mode property protection bit s_irugo read-only s_iwusr to root write modify properties, fill in a attr to SYSFS delete directory file functions The Sysfs_create_remove_filesysfs property passes the firmware code to the kernel,bin_attribute with attribute size (*read) (* Write) can read and write 1 pages at a time 5 subsystem related to the kernel provides the SYSF subtree is actually already registered on the various kobject, and kobject set of relations, The upper layer is usually a subsystem under the SUBSYSTEMSYSFS that is already registered: block device subsystem: Corresponding sys/block, each directory in the corresponding to a registered block device
device Hierarchy core : corresponds to the actual device topology in the sys/devices system. Very important, many other catalogs are copying the hierarchy in him. Bus subsystem: Corresponds to the Sys/bus system Bus View device node subsystem: corresponds to Sys/dev registered device node view firmware subsystem: Corresponding Sys/firmware special tree file subsystem with underlying subsystem: corresponding SYS/FS Registered file System View Kernel subsystem: Corresponds to Sys/kernel kernel configuration item and state information module subsystem: corresponding to Sys/module loaded module information Power SUBSYSTEM: Sys/power system-wide power management data bus has two Ket, One is the device drive set of the bus, one is plugged in on the bus all devices devices and driver relationships with new pointers, symbolic links int sysfs_create_link (struct kobject *kobj,struct kobject *target,char *name); Set the relative connection of the Kobject and Sysfs entry target,int Sysfs_remove_link (struct kobject *kobj,char *name); Remove the symbolic link subsystem is the encapsulation of KET and signals, each keset must belong to a subsystem, Rwsem semaphores are used for serial access to the Kset internal list Sysfs and kobect relationships are used to kobect_add there will be a new directory in the SYSFS, the directory name is the unique name of Kobect, Kobect's parent is the corresponding entry position in the SYSFS, NULL when the highest level directory in Sysfs 6 hot-swap related: Hot plug events, is the kernel space to user space notification is the system configuration changes, Plug-in usb user console switchover, disk partitioning it's going to have to be reported,kobject_add or Kobkect_del after the call to actually generate this event The hotplug_ops in Kset has a pointer to the Struct kset_hotplug_ops struct, and kobject that is not specified in Kset is going to use the parent pointer to find a kset containing kobject, Then use this kset hot plug operation kernel to produce things for the specified kobjectFliter function 0 does not produce an event, let Kset determine whether to send a specific event to the user control get_ktype know the event type called Hot plug when the related subsystem name *name passed to it as a unique parameter Hot-swappable information is passed through environment variables, providing methods for adding environment variables using HotPlug. The class of the 7 class: device model is an abstraction of the underlying implementation details, values focus on the functionality provided, essentially under the sys/class directory Care equipment function bus tracking device, user device function, equipment with SYSFS and user space communication
Kernel device model from Kobject to subsystem
