it is not usual case(merely used such mutibyte locale, eg. ja_JP.ISO-2022-JP).
[background]
before merging minoura-xpg4dl branch(2001), we argued and decided to increase
MB_LEN_MAX 1 -> 32 all CPUARCH(*but* we forgot to change it MD to MI).
without knowing that NetBSD/hp700(mergeing -current 2002) incorrectly set
MB_LEN_MAX=6 (maybe this value taken from FreeBSD). but our setlocale(3)
assumes __mb_len_max_runtime as 32, so that mbrtowc/wcrtomb may overrun.
we have to increase hppa's MB_LEN_MAX upto 32, and change it MD to MI
next libc major bump(scheduled next release 6.0).
from http://www.openssl.org/news/secadv_20100324.txt:
"In TLS connections, certain incorrectly formatted records can cause an OpenSSL
client or server to crash due to a read attempt at NULL".
cpu_pmap_init() and replace pmap_ctx_lock usage with this new ci_ctx_lock
- replace smp_dcache_flush_page_all() with smp_dcache_flush_page_cpuset(),
that flushes only on the set of CPUs not, everyone. add new
dcache_flush_page_cpuset() to flush this page from the D$ only
on the specified set of CPUs.
- add a cpuset to pmap_free_page() and use it when freeing PTE pages
when a pmap is destroyed
- introduce pmap_free_page_noflush(), and use it when we allocated a
page for PTEs but didn't use it and don't need to flush it
- don't bother with pmap_lock in pmap_extract(), the only potential
issue is pseg_get() which is already safe
tested on sb2000, sb2500 and ultra80 with a bunch of various heavy
workloads, and seems to give a clear 1-2% speed up for high-forking /
short lived processes, such as ./configure.
fix the powerpc64 quirk handling by introducing a prefix quirk and
using it as appropriate. fix the (postfix) quirk.
now rump and powerpc64 get along nicely.
libc implementation (such as *BSD and glibc2).
2. don't typedef void * wc{type,trans}_t, suggested by soda@-san.
it may pass through compiler type check, it's harmful.
so i introduce dummy struct __tag_wc{type,trans}_t(iconv_t already does).
no ABI change was made.
mknative-gdb to generate these, but my initial attempt failed and
these ones seem to be about what i'd expect anyway.
suggested by dennis.c.ferguson@gmail.com in PR#43043.
- gmcgarry_ctxsw replaced by yamt-idlelwp
- move nick-hppapmap into the right section
- rtr-xorg-branch is dead
- thorpej-atomic is (bascially) merged to -current
Strongly architect handles so we can more easily detect bogus
handles. This switches us to a full 32 bits for all handles.
Handle the case of FC disks disappearing and then reappearing-
at least at the FC transport level.
Some better and finer control of debug and non-debug printouts.
be needed to update acpiapm_get_powstat() which is currently slightly
broken due to recent rearrangement of acpi_bat(4)'s sensors. (This
approach is in lieu of exporting proplists between kernel entities, and
avoids exposing some internal sysmon_envsys details.)
This was nagging me already yesterday, but I decided to leave it
alone for better compat with old ioconf.c builds. But as it turns
out, new code depends on newly built ioconf.c with a new config(1)
anyway, so renaming is not an issue (at least not at this stage).
While renaming, namespace cfdriver and cfattach in "ioconf" rather
than "comp", since the former reflects the config(5) keyword.
While this is not strictly sensible, it keeps UPDATE=1 builds
rolling if I change some aspect of config (such as adding the
cfdriver/cfattach lists now). This is going away eventually.
driver/attach/data typically present and once some locking is grown
in here, these routines can be made to fail or succeed a component
attachment/detachment atomically.
