be changed in the future to "yes".
If MKDYNAMICROOT == "no", there is no change from existing behaviour
of a static /bin and /sbin (and a few programs in elsewhere).
If MKDYNAMICROOT == "yes", the following changes occur:
in <bsd.own.mk>:
SHLIBDIR?= /lib
SHLINKDIR?= /lib
in various Makefiles, the following entry is DISABLED.
LDSTATIC?=-static
This results in all programs (except those "standalone" programs built
in sys/arch/*/stand) are linked dynamically, the shared linker is moved
from /usr/libexec to /lib (with a compat symlink), and the shared
libraries used by /bin and /sbin programs are moved from /usr/lib to
/lib (with compat symlinks).
and modification of user and group information.
Syslog priority is LOG_INFO, facility is LOG_USER (there is no need to
do this via LOG_AUTH, since the password and group files are world
readable).
Suggested by Hubert Feyrer, after a similar facility in Linux.
report. This file is expected to change daily, and this is not a security
problem. (Also, the most recent dumps are already shown in the daily report.)
quirk table.
* We want to hardwire BMSR_EXTSTAT, not BMSR_EXTCAP, when reading
the TBI BMSR.
* Fetch the GPIO bits from the GPIOR register after an auto-load,
rather than reading from the EEPROM directly.
bits of the K6 cache-control-register: disable the cache; flush the cache;
set the bits; re-enable the cache (all much like programming the pentium
mtrr's). See reference posted to tech-kern; also review there by thorpej.
Add support for cpus where sizeof(register_t) is not necessarily
the same as sizeof(void *). This is the case on SH5 using the
ILP32 ABI. On this cpu db_expr_t is, necessarily, 64-bits.
Unfortunately, in ILP32 mode, ddb will only display the low 32-bits
of any expression, including registers...
Seeq 84220.
Also add an 84220-specific work-around for some braindamage (at least
in the PHY I'm working with) where the PHY always comes out of reset
isolated, regardless of the previous state of the BMCR_ISO bit. This
happens even if the PHY has address zero, which is contrary to the
part's datasheet...
The work-around is only applied if we notice BMCR_ISO is set when it
should be clear following reset. The fix is to wait 30mS and clear
it manually. (The change doesn't stick if it's cleared sooner than this)
The latter's probe doesn't pick up the ethernet controller, and the
attach function needs to set MIIF_NOISOLATE.
We attach it at superio mainly because they share the same region of
address space, and the ethernet controller's interrupt is routed
through the superio.
previous behaviour of storing them with SR.BL clear was in breach
of the SH5 documentation.
Make an effort to catch PANIC traps and dump machine state to the console.
lukem