and RFC4286 (Multicast Router Discovery.) and as shown in the IANA
parameters page available at:
https://www.ietf.org/assignments/icmpv6-parameters/icmpv6-parameters.txt
Also make the array be explicitly 256 entries long, one for each possible
code, which will detect attempts to insert names without deleting the
place holder (and mean a good solid NULL de-ref if too many place holders
are deleted, rather than just random results.)
If VAR is not previously set, call Var_Set to deal with
the special case of VAR_CMD.
If VAR is previously set, and ctxt is VAR_CMD we should do the update
even if VAR_FROM_CMD is set.
bootpages is set to the pages allocated via uvm_pageboot_alloc().
poolpages is calculated from the list of pools nr_pages members.
this brings us closer to having a valid total of pages known by
the system, vs actual pages originally managed.
XXX: poolpages needs some handling for PR_RECURSIVE pools still.
need the results, not speculatively, just in case we might.
Allows operation with some broken servers that get confused
by PWD commands in some situations, and saves server round
trips in the (modern) common case of
ftp ftp://path/name
where we never need to know the results from PWD.
POSIX requires that variables set on the command line
be immutable.
Var_Append needs to pass FIND_CMD and skip append
if found variable has VAR_FROM_CMD flag set.
foo* at bar? with baz
foo* at bar? with barf
Do this by scanning the list of iba's and allocating a new cfparent for
each. Keep track of the shared parent+child combinations by using the
same id for them.
in PR kern/52639, as well as some general cleaning-up...
(As proposed on tech-kern@ with additional changes and enhancements.)
Details of changes:
* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)
* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.
* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.
* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."
* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.
* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).
* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).
* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.
* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.
[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".
[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.
christos