Lines Matching refs:of
9 - the VM subsystem that provides allocations at the granularity of pages (with
11 - the zone allocator subsystem (`<kern/zalloc.h>`) which is a slab-allocator of
12 objects of fixed size.
15 allocator implemented as a collection of zones of fixed size, and overflowing to
37 The zone subsystem provides a `zalloc_permanent*` family of functions that help
48 When flags are expected, exactly one of `Z_WAITOK`, `Z_NOWAIT` or `Z_NOPAGEWAIT`
60 - `Z_ZERO` if zeroed memory is expected (nowadays most of the allocations will
84 - the object type implements some form of security boundary and wants to adopt
89 In the vast majority of cases however, using `kalloc_type` (or `IOMallocType`)
97 `kalloc_type` or one of its variants (like IOKit's `IOMallocType`) and untyped
99 one of its variants (like IOKit's `IOMallocData`). However, this comes with
111 A general theme will be the separation of data/primitive types from pointers,
115 of the types being allocated. Because some scalars actually represent
130 we have typically found that there is a large array of data,
133 misuse of `kalloc_type()` relative to size at compile time, it's default in XNU.
142 An array is simply an allocation of several fixed-size types,
143 and the rules of "fixed-sized types" above apply to them.
153 of an array.
220 <td>Arrays of fixed-sized type</td>
248 <td>Header-prefixed arrays of fixed-sized type</td>
277 correct usage of these macros; with -fbounds-safety disabled, engineers are on
292 All subclasses of `OSObject` must declare and define one of IOKit's
293 `OSDeclare*` and `OSDefine*` macros. As part of those, an `operator new` and
301 manually. If your struct or class is POD (Plain Old Data), then replacing usage of
305 However, if you have non default structors, or members of your class/struct
307 This can be accomplished through one of the following approaches, and it lets you
331 Finally, if you need to decouple the declaration of the operators from
334 declaration and then provide their definition out of line:
347 When a class/struct adopts typed allocators through one of those approaches,
350 automatically provide the implementation of the operators for all of its children:
353 ### The case of `operator new[]`
355 The ABI of `operator new[]` is unfortunate, as it denormalizes
361 of the structure, making it relatively easy to attack with
362 out-of-bounds bugs.
364 For this reason, the default variants of the mixin and the macros
365 presented above will delete the implementation of `operator new[]`
377 The only accepted ways of using `operator new/delete` and their variants are the ones
379 should use the appropriate typed allocator API based on the semantics of the memory
385 The blessed way of wrapping and passing a C++ type allocation for use in the
390 wrapping a structure of type `T`. For each unique `T` being used, the
391 `OSValueObject<T>` must be instantiated in a module of your kernel extension,