Lines Matching defs:kstat

32  * Definition of general kernel statistics structures and /dev/kstat ioctls
42 typedef int kid_t; /* unique kstat id */
45 * Kernel statistics driver (/dev/kstat) ioctls
55 * /dev/kstat ioctl usage (kd denotes /dev/kstat descriptor):
65 * The generic kstat header
68 typedef struct kstat {
73 struct kstat *ks_next; /* kstat chain linkage */
74 kid_t ks_kid; /* unique kstat ID */
78 char ks_name[KSTAT_STRLEN]; /* kstat name */
79 uchar_t ks_type; /* kstat data type */
80 char ks_class[KSTAT_STRLEN]; /* kstat class */
81 uchar_t ks_flags; /* kstat flags */
82 void *ks_data; /* kstat type-specific data */
84 size_t ks_data_size; /* total size of kstat data section */
89 int (*ks_update)(struct kstat *, int); /* dynamic update */
91 int (*ks_snapshot)(struct kstat *, void *, int);
92 void *ks_lock; /* protects this kstat's data */
104 caddr32_t ks_next; /* struct kstat pointer */
129 * kstat structure and locking strategy
131 * Each kstat consists of a header section (a kstat_t) and a data section.
134 * as well as all changes to kstat headers. kstat data sections are
135 * *optionally* protected by the per-kstat ks_lock. If ks_lock is non-NULL,
136 * kstat clients (e.g. /dev/kstat) will acquire this lock for all of their
137 * operations on that kstat. It is up to the kstat provider to decide whether
138 * guaranteeing consistent data to kstat clients is sufficiently important
141 * ks_lock to point to that mutex, then kstat data locking is free.
143 * NOTE: variable-size kstats MUST employ kstat data locking, to prevent
144 * data-size races with kstat clients.
147 * in the kstat header so that users don't have to be exposed to all of the
166 * kstat time
175 * kstat identity (KID)
177 * Each kstat is assigned a unique KID (kstat ID) when it is added to the
178 * global kstat chain. The KID is used as a cookie by /dev/kstat to
179 * request information about the corresponding kstat. There is also
180 * an identity associated with the entire kstat chain, kstat_chain_id,
181 * which is bumped each time a kstat is added or deleted. /dev/kstat uses
182 * the chain ID to detect changes in the kstat chain (e.g., a new disk
187 * kstat module, kstat instance
190 * that created the kstat. In cases where there can only be one instance,
196 * kstat name
198 * ks_name gives a meaningful name to a kstat. The full kstat namespace
200 * module. kstat_create() will fail if you try to create a kstat with
202 * allowed in kstat names, but strongly discouraged, since they hinder
207 * kstat type
209 * The kstat mechanism provides several flavors of kstat data, defined
210 * below. The "raw" kstat type is just treated as an array of bytes; you
213 * Some kstat types allow multiple data structures per kstat, e.g.
215 * kstat data type.
218 * get this information, read out the standard system kstat "kstat_types".
235 * kstat class
237 * Each kstat can be characterized as belonging to some broad class
241 * hat, streams, kstat, and misc. (The kstat class encompasses things
246 * kstat flags
254 * kstat data section; instead, you will set the ks_data
261 * The size of the kstat you are creating will vary over time.
262 * For example, you may want to use the kstat mechanism to
263 * export a linked list. NOTE: The kstat framework does not
266 * kstat data locking to prevent data-size races with kstat
267 * clients. See the section on "kstat snapshot" for details.
271 * Makes the kstat's data section writable by root.
273 * this; permission checking is handled in the kstat driver.
277 * Indicates that this kstat is to be persistent over time.
279 * kstat as dormant; a subsequent kstat_create() reactivates
280 * the kstat. This feature is provided so that statistics
286 * The following flags are maintained by the kstat framework:
290 * For persistent kstats, indicates that the kstat is in the
295 * This flag is set when a kstat is in a transitional state,
297 * kstat clients must not attempt to access the kstat's data
302 * Indicates that this kstat contains long strings (which
303 * are stored outside of the kstat data section). When copied
319 * The kstat mechanism allows for an optional ks_update function to update
320 * kstat data. This is useful for drivers where the underlying device
322 * constantly keeping the kstat data section up to date, you can supply a
323 * ks_update function which updates the kstat's data section on demand.
350 * are needed to perform kstat snapshots (see below).
352 * No kstat locking should be done inside the ks_update routine. The caller
353 * will already be holding the kstat's ks_lock (to ensure consistent data).
362 * In order to get a consistent view of a kstat's data, clients must obey
363 * the kstat's locking strategy. However, these clients may need to perform
366 * (e.g. if you're holding a disk's kstat lock which is ultimately required
368 * activity is serialized at the kstat lock), device timing problems, etc.
370 * To avoid these problems, kstat data is provided via snapshots. Taking
372 * acquire the kstat's data lock, copy the data into the buffer ("take the
373 * snapshot"), and release the lock. This ensures that the kstat's data lock
381 * If you create a kstat whose data is, say, a linked list, you must provide
414 * (2) Data gets copied from the kstat to the buffer on KSTAT_READ,
415 * and from the buffer to the kstat on KSTAT_WRITE.
420 * strings (KSTAT_DATA_STRING) need special handling. The kstat driver
541 * Retrieve the pointer of the string contained in the given named kstat.
547 * named kstat.
714 extern void kstat_init(void); /* initialize kstat framework */
719 * The typical sequence to add a kstat is:
732 * allocates memory for the entire kstat (header plus data), initializes
734 * a unique KID, and puts the kstat onto the system's kstat chain.
735 * The returned kstat is marked invalid (KSTAT_FLAG_INVALID is set),
739 * By default, kstats are exported to all zones on the system. A kstat may be
753 * Once the kstat is completely initialized, kstat_install() clears the
754 * INVALID flag, thus making the kstat accessible to the outside world.
757 * Removing a kstat from the system
759 * kstat_delete(ksp) removes ksp from the kstat chain and frees all
761 * you must NOT be holding that kstat's ks_lock. Otherwise, you may
762 * deadlock with a kstat reader.
777 * creates a new kstat, as usual. However, kstat_delete() does not
778 * actually delete the kstat: it performs one final update of the data
779 * (i.e., calls the ks_update routine), marks the kstat as dormant, and
782 * e.g. if the provider is going away). kstat clients can still access
783 * the dormant kstat just like a live kstat; they just continue to see
784 * the final data values as long as the kstat remains dormant.
786 * dormant kstat and return a pointer to it, without altering any fields.