the same name. Silently return EEXIST if this happens.
vinum_scandisk: Collect drive numbers, not pointers, to avoid problems
of relocated drives.
Tripped-over-by: Bernd Walter <ticso@cicely.de>
time out on an operation. Under these circumstances, vinum(8) will
automatically start another daemon. Add a pid for the daemon, so that
an overtaken daemon will discover that it's no longer in favour, and
will crawl into a corner and die.
256 kB instead of 16 kB.
Pointed-out-by: Steve Taylor <staylor@cybernet.com>
Modify description of start command to include 'start' with no
parameters, which reads the config from all drives found on the
system.
the wrong module can cause confusion, including loading both versions
(which conflict with each other) and incorrect ioctls, which cause
unintelligible error messages.
Extend 'start' command: if used without any parameters, vinum scans
all disks known to devstat for vinum drives and reads their
configuration.
incorrect; returning NULL here means that the dispatcher won't send any
response back to the caller, which means the caller will sit there waiting
until it times out. I don't know how this ever worked before. The effect
is that using 'ypset foo' to get the local ypbind to change servers would
work, but would sit there hanging for a long time for no reason.
Under certain conditions (possibly associated with heavy load), ypserv will
fork() child processes that don't exit like they're supposed to. I think
this is because of some suspect logic in the ypproc_all procedure. I updated
it to use what I hope is a more bulletproof approach.
Also tweaked yp_svc_run() a little so that the 'are we a child?' test happens
at every pass through the for(;;) loop, not just immediately after returning
from svc_getreqset2().
- Add syscons.4.
If there still are errors, whether technical or grammatical, they are
entirely mine, not the reviewers'.
Reviewed by: sos, jkh, archie, Nick Hilliard <nick@iol.ie>
I still have reservations about choosing the ISC client over the WIDE client,
but I believe the FreeBSD community in general seems to prefer this choice.
Also OpenBSD uses this version and msmith showed that the ISC client gives
us more choices in how we hook the client into sysinstall and /etc/rc*
the display wrapped around.
This decreases the default maximum number of disks shown to 2, so things
don't wrap around so easily. Also, it fixes the header display issues.
Submitted by: Bruce Evans <bde@FreeBSD.ORG>
peripheral drivers can determine where in the devstat(9) list they are
inserted.
This requires recompilation of libdevstat, systat, vmstat, rpc.rstatd, and
any ports that depend on the devstat code, since the size of the devstat
structure has changed. The devstat version number has been incremented as
well to reflect the change.
This sorts devices in the devstat list in "more interesting" to "less
interesting" order. So, for instance, da devices are now more important
than floppy drives, and so will appear before floppy drives in the default
output from systat, iostat, vmstat, etc.
The order of devices is, for now, kept in a central table in devicestat.h.
If individual drivers were able to make a meaningful decision on what
priority they should be at attach time, we could consider splitting the
priority information out into the various drivers. For now, though, they
have no way of knowing that, so it's easier to put them in an easy to find
table.
Also, move the checkversion() call in vmstat(8) to a more logical place.
Thanks to Bruce and David O'Brien for suggestions, for reviewing this, and
for putting up with the long time it has taken me to commit it. Bruce did
object somewhat to the central priority table (he would rather the
priorities be distributed in each driver), so his objection is duly noted
here.
Reviewed by: bde, obrien
the mount is completely active, causing the next few commands attempting
to manipulate data on the mount to fail. mount_mfs's parent now tries
to wait for the mount point st_dev to change before returning, indicating
that the mount has gone active.
convince myself that nothing will break if we permit IP input while
interface addresses are unconfigured. (At worst, they will hit some
ULP's PCB scan and fail if nobody is listening.) So, remove the restriction
that addresses must be configured before packets can be input. Assume
that any unicast packet we receive while unconfigured is potentially ours.
