Searched full:object (Results 1 – 25 of 509) sorted by relevance
12345678910>>...21
| /Documentation/core-api/ |
| D | debug-objects.rst | 2 The object-lifetime debugging infrastructure
21 debugobjects is not changing the data structure of the real object so it
29 object type and add calls into the debug code at appropriate places. The
30 data structure to describe the object type needs at minimum the name of
31 the object type. Optional functions can and should be provided to fixup
53 Each of these functions takes the address of the real object and a
54 pointer to the object type specific debug description structure.
71 object is called.
73 When the real object is already tracked by debugobjects it is checked,
74 whether the object can be initialized. Initializing is not allowed for
[all …]
|
| D | assoc_array.rst | 8 This associative array implementation is an object container with the following
19 permits an object to be located in multiple arrays simultaneously.
24 4. Index keys must be unique. Inserting an object with the same key as one
25 already in the array will replace the old object.
52 pack leaf object pointers into spare space in the node rather than making an
53 extra branch until as such time an object needs to be added to a full node.
105 this was for insertion, the new object is _not_ released by this function,
132 2. Get a chunk of an object's index key::
134 unsigned long (*get_object_key_chunk)(const void *object, int level);
136 As the previous function, but gets its data from an object in the array
[all …]
|
| /Documentation/filesystems/caching/ |
| D | backend-api.rst | 48 * "fsdef" which should point to the object representation for the FS-Cache
50 here. FS-Cache keeps the caller's reference to the index object if
114 The fields that might be of use to the backend describe the object
116 The object definition contain functions supplied by the netfs for loading
121 * In-cache object representation::
137 the case of CacheFS, they're embedded in CacheFS's internal object
141 that refer to a particular object. In such a case it should be printed
144 Each object contains a pointer to the cookie that represents the object it
145 is backing. An object should retired when put_object() is called if it is
147 initialised by calling fscache_object_init(object).
[all …]
|
| D | object.rst | 4 In-Kernel Cache Object Representation and Management
13 (*) Object management state machine.
26 FS-Cache maintains an in-kernel representation of each object that a netfs is
41 correspond, but the cookies tree is a superset of the union of the object trees
93 Object Management State Machine
96 Within FS-Cache, each active object is managed by its own individual state
97 machine. The state for an object is kept in the fscache_object struct, in
98 object->state. A cookie may point to a set of objects that are in different
105 representations are hierarchical, and it is expected that an object must
106 be created or accessed with respect to its parent object.
[all …]
|
| D | operations.rst | 124 conjunction with any other operation on the object being operated upon.
146 int fscache_submit_op(struct fscache_object *object,
149 int fscache_submit_exclusive_op(struct fscache_object *object,
157 object and return 0. -ENOBUFS will be returned if the object specified is
160 The operation manager will defer operations on an object that is still
162 operation of conflicting exclusivity is in progress on the object.
171 FSCACHE_OP_WAITING as described above and check the state of the object if
172 necessary (the object might have died while the thread was waiting).
177 (4) The operation holds an effective lock upon the object, preventing other
|
| /Documentation/gpu/ |
| D | drm-mm.rst | 54 void *object;
61 as a whole, and there will be others for each object created by the
63 TTM_GLOBAL_TTM_MEM. The size field for the global object should be
71 object TTM to provide a pool for buffer object allocation by clients and
72 the kernel itself. The type of this object should be
77 object, ttm_global_item_ref() is used to create an initial reference
111 Buffer object allocation is relatively straightforward and largely
113 object.
126 DRM Memory Manager object which provides an address space pool for
127 object allocation.
[all …]
|
| /Documentation/devicetree/bindings/mfd/ |
| D | cirrus,lochnagar.yaml | 43 type: object
47 type: object
70 type: object
74 type: object
81 type: object
88 type: object
95 type: object
102 type: object
109 type: object
116 type: object
[all …]
|
| /Documentation/firmware-guide/acpi/dsd/ |
| D | data-node-references.rst | 15 A reference consist of the device object name followed by one or more
18 parent object i.e. either the device object or another hierarchical data
23 or postfixes). The same ACPI object shall include the _DSD property extension
28 "reg" property shall be omitted from the ACPI object's _DSD properties and the
37 device object reference to DEV0 and under that device object, a
38 hierarchical data extension key "node@1" referring to the NOD1 object
40 the ANOD object which is also the final target node of the reference.
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-acpi | 6 object associated with the device object. For example,
17 This attribute indicates the PNP IDs of the device object.
19 CCCCCCCC contains device object's PNPID (_HID or _CID).
26 device object. For example, PNP0103.
34 This attribute contains the output of the device object's
41 This attribute contains the output of the device object's
50 This attribute contains the output of the device object's
58 this device object. This file exists for every device
59 object that has _EJ0 method.
|
| D | sysfs-kernel-livepatch | 17 object (vmlinux or a module) in which it patched functions.
50 What: /sys/kernel/livepatch/<patch>/<object>
55 The object directory contains subdirectories for each function
56 that is patched within the object.
58 What: /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
68 name in kallsyms for the patched object.
|
| D | sysfs-class-devfreq-event | 7 The name of devfreq-event object denoted as 'event(x)' which
8 includes the unique number of 'x' for each devfreq-event object.
15 the name of the devfreq-event object. This attribute is
24 object. If the device is enabled, the value of attribute is
|
| D | dell-smbios-wmi | 26 3) In the 'length' object store the size of the buffer you
29 4) In this buffer object, prepare as necessary for the SMBIOS
39 7) The output will be returned in the buffer object.
41 8) Be sure to free up your allocated object.
|
| D | sysfs-class-devfreq | 7 The name of devfreq object denoted as ... is same as the
15 of the corresponding devfreq object.
22 governor used by the corresponding devfreq object.
29 frequency of the corresponding devfreq object. Same as
38 predicted target frequency of the corresponding devfreq object.
46 object. The values are represented in ms. If the value is
74 sets the requested frequency for the devfreq object if
82 the available frequencies of the corresponding devfreq object.
|
| /Documentation/devicetree/bindings/iio/temperature/ |
| D | mlx90632.txt | 6 and MLX90632 is most suitable for consumer applications where measured object
8 of measurement below 1 degree Celsius in object temperature range for
16 Since measured object emissivity effects Infra Red energy emitted, emissivity
17 should be set before requesting the object temperature.
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | lontium,lt9611.yaml | 40 type: object
50 type: object
60 type: object
71 type: object
82 type: object
93 type: object
103 type: object
|
| D | toshiba,tc358762.yaml | 28 type: object
38 type: object
50 type: object
60 type: object
72 type: object
|
| D | cdns,mhdp8546.yaml | 60 type: object
72 type: object
77 type: object
82 type: object
87 type: object
92 type: object
|
| D | ti,tfp410.yaml | 38 type: object
43 type: object
50 type: object
71 type: object
78 type: object
|
| /Documentation/vm/ |
| D | slub.rst | 54 P Poisoning (object and padding)
84 a result of storing the metadata (for example, caches with PAGE_SIZE object
132 SLUB can validate all object if the kernel was booted with slub_debug. In
172 of a slab cache with large object sizes into one high order
189 INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58
193 Object (0xc90f6d20): 31 30 31 39 2e 30 30 35 1019.005
221 If SLUB encounters a corrupted object (full detection requires the kernel
235 INFO: Object <address> <object information>
241 (Object allocation / free information is only available if SLAB_STORE_USER is
244 2. The object contents if an object was involved.
[all …]
|
| D | zsmalloc.rst | 12 any object of size PAGE_SIZE/2 or larger would occupy an entire page.
17 pages act as a single higher-order page i.e. an object can span 0-order
29 location of the allocated object. The reason for this indirection is that
32 is very small. So, before using the allocating memory, the object has to
58 object size zspage stores
|
| /Documentation/firmware-guide/acpi/ |
| D | namespace.rst | 19 receiving ACPI hotplug notification events. For each device object
85 The following naming conventions apply to object names in the ACPI
200 ACPI namespace representation of the given object and 'instance' is used
201 for distinguishing different object of the same 'bus_id' (it is
204 The value of 'bus_id' depends on the type of the object whose name it is
208 | | Object/Feature | Table | bus_id |
241 The object's source is an ACPI namespace node (as indicated by the
242 named object's type in the second column). In that case the object's
246 The struct acpi_device object is created for a fixed hardware
251 The struct acpi_device object is created for an ACPI namespace node
[all …]
|
| /Documentation/filesystems/ |
| D | xfs-self-describing-metadata.rst | 63 metadata object contains some form of unique identifier in a well known
65 hence parse and verify the metadata object. IF we can't independently identify
66 the type of metadata in the object, then the metadata doesn't describe itself
76 metadata object at runtime, during forensic analysis or repair.
108 object, we don't know what inode it belongs to and hence have to walk the entire
112 owner field in the metadata object, we can immediately do top down validation to
118 contents of the owner field are determined by the type of metadata object we are
130 For example, we can determine whether a metadata object is supposed to be free
133 compared to when the metadata object itself was last written. If the free space
134 block is more recent than the object and the object's owner, then there is a
[all …]
|
| D | directory-locking.rst | 19 2) object creation. Locking rules: same as above, but the lock is taken
22 3) object removal. Locking rules: caller locks parent, finds victim,
77 (1) if object removal or non-cross-directory rename holds lock on A and
80 the parent of object and it would have to lock the parent).
90 non-directory object, except renames, which take locks on source and
107 Any contended object is either held by cross-directory rename or
110 is blocked on belongs to child of that object due to (1).
114 would have a contended child and we had assumed that no object is its
118 Consider the object blocking the cross-directory rename. One
140 ability to check that directory is a descendent of another object. Current
|
| /Documentation/RCU/ |
| D | rculist_nulls.rst | 35 * Because a writer could delete object, and a writer could
36 * reuse these object before the RCU grace period, we
37 * must check key after getting the reference on object
39 if (obj->key != key) { // not the object we expected
76 "If the object is moved from one list to another list in-between the
78 object has moved to the end of a new list, the traversal will not
79 complete properly on the list it should have, since the object will
116 But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
140 a race (some writer did a delete and/or a move of an object
144 the beginning. If the object was moved to the same chain,
[all …]
|
| /Documentation/devicetree/bindings/media/i2c/ |
| D | adv7180.yaml | 39 type: object
45 type: object
89 type: object
94 type: object
119 type: object
124 type: object
|
12345678910>>...21