Here are some enhancements to sushi's System Maintenance menu.
To summarize the changes:
* Make a backup of the file before modifying it.
* Fixes to get all menus/forms working.
* Missing/invalid settings (like in rc.conf and inetd.conf)
have been added/removed.
* Most files don't get overwritten now but are edited instead.
So specials settings in e.g. /etc/rc.conf don't get lost now.
* Some help menu fixes. ($NetBSD$ tag has been removed because I
don't see how it would be useful for either user or developer).
The changes are:
* rename "Security and Users" to "Users and Groups"
* use default settings in /etc/usermgmt.conf (if it exists)
when adding a new user.
* fix output for 'List users'.
* add the following menu's: Modify user, Change password, Add group,
List groups, Delete group.
related scripts:
* Don't check if the daemons ntpdate, virecover, ipfilter, samba
are running (because they get only started at boot, or are wrappers
to other scripts).
* Exclude lines with 'not supported' and 'not found' in the ouput.
* Top 15 cpu {usage,time} and memory: show really the 15 top daemons
(instead of 14) and fix cpu time.
in interrupt context.
if this is not a desired restriction, then those functions
should be reviewed for safety, at least protecting pool_head_slock
with splvm()
and exception handling have a chance of working properly.
- creates libgcc, libgcc_eh and libgcc_s
- updates LIBGCC_SPEC to use them appropriately.
There's a hack in here at the moment with respect to libgcc_so in that it
is preferable to link against libgcc_so will only when -shared-libgcc is
specified (the c++ frontend does this automatically.) Configurations where
LINK_EH_SPEC is defined already do this. The gcc configuration for
NetBSD/alpha and another NetBSD platform (I forget which) actually define
LINK_EH_SPEC probably by accident rather than design.
- updates share/mk to use the compiler's knowledge of what needs linking into
libraries and executables. This removes an hppa hack.
- updates the sets for the newly created libgcc* files.
- support for linking against the _pg version of libgcc has been removed.
called with every buffer written through spec_strategy().
Used by fss(4). Future file-system-internal snapshots will need them too.
Welcome to 1.6ZK
Approved by: Jason R. Thorpe <thorpej@netbsd.org>
The benefits of having the symbol table available by default (easier
debugging of core dumps, etc) outweigh the minor (3%) increase in
the size of the distribution, and end-users can always strip(1) their
systems if they're concerned about that 3% of disk space.
This simplifies using ld with ${DESTDIR}/usr/lib whilst retaining the
(slightly faster) absolute links for the run-time libraries.
Per discussion on tech-toolchain.
(Side note; install(1) -l r needs the source to be prefixed with ${DESTDIR}
to operate correctly, which makes it non trivial to enable '-l r' by default
for all ${INSTALL_SYMLINK}s)
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
code does only device probe for nonstandard I/O locations on ISA bus,
and is not useful for other attachments
drop the list of tested stuff; that information doesn't belong in this
manpage
lukem