Loading...
doc/allocators/api-basics.md xnu-12377.121.6 xnu-8792.61.2
--- xnu/xnu-12377.121.6/doc/allocators/api-basics.md
+++ xnu/xnu-8792.61.2/doc/allocators/api-basics.md
@@ -1,6 +1,4 @@
 # XNU Allocators best practices
-
-The right way to allocate memory in the kernel.
 
 ## Introduction
 
@@ -129,8 +127,6 @@
   smaller than `KALLOC_SAFE_ALLOC_SIZE`. When this is not the case,
   we have typically found that there is a large array of data,
   or some buffer in that type, the solution is to outline this allocation.
-  kernel extensions must define `KALLOC_TYPE_STRICT_SIZE_CHECK` to turn
-  misuse of `kalloc_type()` relative to size at compile time, it's default in XNU.
 - for union types, data/pointer overlaps should be avoided if possible.
   when this isn't possible, a zone should be considered.
 
@@ -175,8 +171,6 @@
       <tt>kalloc_data(size, flags)</tt><br/>
       <tt>krealloc_data(ptr, old_size, new_size, flags)</tt><br/>
       <tt>kfree_data(ptr, size)</tt><br/>
-      <tt>kfree_data_counted_by(ptr_var, count_var)</tt><br/>
-      <tt>kfree_data_sized_by(ptr_var, byte_count_var)</tt><br/>
       <tt>kfree_data_addr(ptr)</tt>
       </p>
       <p>
@@ -267,15 +261,6 @@
     </td>
   </tr>
 </table>
-
-`kfree_data_counted_by` and `kfree_data_sized_by` are used when working with
--fbounds-safety and pointers with __counted_by and __sized_by modifiers,
-respectively. They expect both their pointer and size arguments to be
-modifiable, and the pointer and size will be set to 0 together, in accordance
-with -fbounds-safety semantics. Please note that arguments are evaluated
-multiple times. When -fbounds-safety is enabled, the compiler can help ensuring
-correct usage of these macros; with -fbounds-safety disabled, engineers are on
-their own to ensure proper usage.
 
 ## C++ classes and operator new.
 
@@ -381,13 +366,7 @@
 for any other type).
 
 ### Wrapping C++ type allocation in container OSObjects
-
 The blessed way of wrapping and passing a C++ type allocation for use in the
-libkern collection is using `OSValueObject`. Please do not use `OSData` for this
+libkern collection is using `OSValueObject`. Please do no use OSData for this
 purpose as its backing store should not contain kernel pointers.
 
-`OSValueObject<T>` allows you to safely use an `OSData` like API surface
-wrapping a structure of type `T`. For each unique `T` being used, the
-`OSValueObject<T>` must be instantiated in a module of your kernel extension,
-using `OSDefineValueObjectForDependentType(T);`.
-