Make the man page reflec t the code a bit better.
Specifically, note the condition of the memory on initial and subsequent allocations is different.
This commit is contained in:
parent
f7af5c6f92
commit
9e5d1d1b57
@ -63,8 +63,11 @@ The zone allocator keeps track of which items are in use and which
|
||||
aren't, and provides functions for allocating items from the zone and
|
||||
for releasing them back (which makes them available for later use).
|
||||
.Pp
|
||||
The zone allocator stores state information inside the items proper,
|
||||
so structures that will be managed by the zone allocator must reserve
|
||||
The zone allocator stores state information inside the items proper
|
||||
while they are not allocated,
|
||||
so structures that will be managed by the zone allocator
|
||||
and wish to use the type stable property of zones by leaving some fields
|
||||
pre-filled between allocations, must reserve
|
||||
two pointers at the very beginning for internal use by the zone
|
||||
allocator, as follows:
|
||||
.Bd -literal
|
||||
@ -75,6 +78,12 @@ struct my_item {
|
||||
};
|
||||
.Ed
|
||||
.Pp
|
||||
Alternatively they should assume those entries corrupted
|
||||
after each allocation. After the first allocation of an item,
|
||||
it will have been cleared to zeroes, however subsequent allocations
|
||||
will retain the contents as of the last free, with the exception of the
|
||||
fields mentioned above.
|
||||
.Pp
|
||||
Zones are created in one of two fashions, depending how far along the
|
||||
boot process is.
|
||||
.Pp
|
||||
|
Loading…
Reference in New Issue
Block a user