discontinued draft for hkp servers, in lieu of any official rfc.
the post method for adding keys to the server has not been implemented.
not until i've gone through all of the implications, anyway.
hkp servers serve up pgp public keys over http. the default port is 11371,
but it can be any port, specifiable at run time. whilst this hkpd will
return valid html to browsers, it is aimed at the ''machine readable''
side, using the ''&options=mr'' option to the http get string.
this hkpd server will get hooked into the build at a later date.
limit values from the device driver, remove the high_limit and low_limit
entries from the hw.dbcool<#>.<sensor> sysctl(8) tree. These limits are
now directly accessible via envstat(8). Simplify the remaining code
somewhat.
No objections raised on either tech-kern@ or current-users@
XXX The fan controllers's parameters (including those that are tied to
XXX temperature sensors) are still in sysctl, since there isn't any clean
XXX way to implement the fan controllers in sysmon_envsys yet. It is on
XXX my To-Do list...
for paddr_t values under i386 PAE. Use ctob() instead.
Although amd64 is not affected by this vaddr_t vs paddr_t issue (both
having the same size), for the sake of completeness, switch to
ctob() when manipulating paddr_t/psize_t entities in amd64 machdep.c.
Compile tested for i386 and amd64. No regression expected.
(instead of size_t) to avoid possible overflow when system may have more
than 4GB of memory (like PAE).
The behavior of rbus_min_start_hint() remains the same. While here, fix
printf's format strings (paddr_t => PRIxPADDR).
Use ctob() and cast physmem to psize_t to avoid losing bits above 4GB.
Comes from PAE patch from Jeremy Morse; adaptation by me.
Compile tested for GENERIC only. No regression expected.
* * *
XXX: The internal memory tracking of ACPICA, available when
ACPI_DBG_TRACK_ALLOCATIONS is defined, has been removed
from ACPI_DEBUG.
This is due to the instability of the ABI of ACPICA.
If the memory tracking is enabled, ACPICA will insert a header
to each memory allocation. As a consequence, when ACPI specific
code is loaded as a kernel module and the running kernel has
been compiled with ACPI_DEBUG, the result is an instant panic.
This happens because of unaligned memory access when the code
tries to use ACPI_FREE for a buffer obtained via ACPI_ALLOCATE,
AcpiEvaluateObject(), and related calls.
If the involved memory statistics are required, a separate constant
ACPI_DEBUG_ALLOC is available in options(4) for ACPI_DEBUG kernels.
* * *
Discussed with, and ok'ed by, jmcneill@ and pooka@.
