files, they are appended to the end of etc/defaults/rc.conf.
So rename them to rc.conf.append for clarity, as suggested by mrg@. Adapt
Makefile accordingly.
rc.conf file. This one should reside under etc/etc.${MACHINE}/, and will
get automatically appended to etc/defaults/rc.conf at build time if present.
This is used by i386 and amd64 to append a small MD rc.conf(5) configuration
at the end of the defaults/rc.conf file, so that powerd(8) can be started
by default when we are running in a Xen environment. This is needed to support
save/restore functions for domains.
From all the alternatives proposed to fix that issue (from /etc/rc.conf
parsing in postinstall to etc/defaults/rc.conf arch-hooks) I believe
this one will appease everyone because it:
- does not touch etc/defaults/rc.conf template file,
- patches it at build time for MD hooks only when required,
- does not need to parse/modify a user-specified file like /etc/rc.conf (which
is a complex, error-prone operation),
- only enables powerd(8) by default when conditions are met (Xen environment)
while still allowing root to shoot himself in the foot if he wants to
override this manually in /etc/rc.conf.
See also http://mail-index.netbsd.org/tech-userlevel/2011/07/25/msg005246.html
route6d is in /usr/sbin, and thus on systems with separate / and /usr,
/etc/rc.d/route6d can be run before /usr is mounted, resulting in
route6d mysteriously failing to start.
by /etc/rc. Similarly for printf with a format that does not end with
"\n". Previously, the partial line would not be visible on the console
until a newline was printed, possibly after an annoying delay.
This is done by adding echo() and printf() shell functions to rc.subr,
so that naive use of the echo and printf commands in rc.d scripts will
call these functions instead of the underlying commands. These shell
functions send a new "nop" metadata message after the partial line, and
the rc_postprocess function in /etc/rc disentangles the partial line of
plain output from the metadata "nop".
Also add a "-n" option to the print_rc_normal function in rc.subr,
and make some cosmetic changes.
we migrate to Kyua (atf v2), so it's better to use a generic name that does
not depend on the specific implementation. Also, this user has not gone
out yet into any stable release, so we can easily rename it.
Suggested by jruoho@.
Even after almost a lost decade since NetBSD/luna68k was
switched to using ELF format by default back in 2001,
actually only one fix (bus.h) is required for a GENERIC kernel itself
to get multiuser login: prompt on a real hardware. Hurrahhh!!!
Demonstrated with a working Xorg mono server on the NetBSD booth
at Open Source Conference 2011 Kansai @ Kyoto:
http://www.ospn.jp/osc2011-kyoto/
"Very impressed," commented by Tomoko YOSHIDA,
Program Committee Chair of the Conference,
and some other OMRON guys.
Special Thanks to Tadashi Okamura, for providing
a working SX-9100/DT "LUNA" for this mission.
Changes details:
sys/arch/luna68k/include/bus.h
- handle stride properly even on multi and region ops for MI spc(4)
- also fix stride handling of (currently unused) 2 and 4 byte ops
sys/arch/luna68k/conf/Makefile.luna68k
sys/arch/luna68k/conf/kern.ldscript.head
sys/arch/luna68k/conf/kern.ldscript.tail
- build a faked a.out kernel using elf2aout(8) tool
and a linker script derived from cats and shark
for the LUNA firmware that loads a.out binary directly
via network or from a UNIOS partition on a local disk
sys/arch/luna68k/dev/omrasops.c
sys/arch/luna68k/dev/omron_rfont.h
- use the original OMRON font derived from 4.4BSD-Lite/luna68k
rather than gallant19 which is used on Sun workstations
(XXX omrasops.c should be rewritten to use generic wsfont(4))
distrib/luna68k/*
distrib/utils/sysinst/arch/luna68k/*
etc/etc.luna68k/MAKEDEV.conf
etc/etc.luna68k/Makefile.inc
sys/arch/luna68k/conf/INSTALL
- build a ramdisk based INSTALL kernel with sysinst(8) for luna68k
- also build an installation iso image for luna68k
sys/arch/luna68k/conf/GENERIC
- enable SYSVSHM (and other SYSV*) options for Xorg server
More Xorg changes (which need some more cleanup) and
isiboot.c fixes will come soon.
in a simpler manner. This replaces btattach, btconfig, bthcid, btdevctl
and sdpd scripts, and also should not require any configuration settings
other than "bluetooth=YES", though the full range of configurations is
still possible.
dyoung