Even though I believe this is a good change, it does
have the potential to break certain clients, so it's
good to document the reasoning behind the change.
a run-queue. If the priority is numerically raised only change lowpri
if we're certain it will be correct. Some slop is allowed however
previously we could erroneously raise lowpri for an idle cpu that a
thread had recently run on which lead to errors in load balancing
decisions.
can't find fsck_4.2bsd because there was no fstab file saying what
filesystem type it is looking at so it got the filesystem type from
the disk's label. When that fails admins who haven't been in this
situation before are most likely to try "fsck -t ufs /dev/ad0s1a" because
ufs is the type used in fstab files on working systems but that also fails
complaining it can't find fsck_ufs.
This just sets it up so /stand in the MFS image (/sbin is a symlink
to /stand) includes hard links pointing fsck_4.2bsd and fsck_ufs to
fsck_ffs which is what is present in /sbin on installed systems.
Prodded by: obrien
MFC after: 1 day
it down to where it belongs.
Document 'all-depends-list' target and bump doc date.
PR: 119519
Submitted by: Yuri Pankov <yuri.pankov@gmail.com>
Reviewed by: flz
Use ioctl() to get the window size in iostat(8), and force a new
header to be prepended to the output every time the current
window size changes. Change the number of lines before each
header to `rows - 3' when the terminal is resized, so that the
full terminal length can be used for output lines.
PR: bin/119705
Submitted by: keramida
Approved by: maxim
MFC after: 2 weeks
GNU tar changed -l to match SUSv2 a couple of years ago,
so bsdtar no longer needs to pander to this particular GNUism.
Thanks to: Debian maintainers
MFC after: 7 days
and newer were supported upgrade paths to -current. After today's
commits, 6.0-RELEASE and newer is supported for jumping to current.
Make that clear in the UPDATING entry. For the pedants out there,
upgrading from FreeBSD_version 600029 and newer should still work.
This represents a point from May 29, 2005 forward. The prior date was
October 16th 2004.
to files, such as ktrace output, under CODA_VERBOSE. Otherwise, each
such call to VOP_WRITE() results in a kernel printf.
MFC after: 3 days
Obtained from: NetBSD
shell. This would break them for floppy based fixit mode which still
seems to use /stand except that vi(1) and more(1) don't exist in /stand
on the fixit floppy so it really doesn't matter what these settings are
there. These paths work for CD-based fixit mode.
This is just "temporary" and on its way to 7.0-REL. I'm too chicken to
make what is probably the correct adjustment this close to release. It
seems /mnt2 is just a symbolic link, and stuff really gets mounted as
/dist. Adjusting paths to that for 8.X is probably the right thing to
do and I'll try that after 7.0 is done.
Noticed by: gallatin
MFC after: 1 day
cases which are used mainly by regression tests.
As usual, the cutoff for tiny args was not correctly translated to
float precision. It was 2**-54 but 2**-24 works. It must be about
2**-precision, since the error from approximating log(1+x) by x is
about the same as |x|. Exhaustive testing shows that 2**-24 gives
perfect rounding in round-to-nearest mode.
Similarly for the cutoff for being small, except this is not used by
so many other functions. It was 2**-29 but 2**-15 works. It must be
a bit smaller than sqrt(2**-precision), since the error from
approximating log(1+x) by x-x*x/2 is about the same as x*x. Exhaustive
testing shows that 2**-15 gives a maximum error of 0.5052 ulps in
round-to-nearest-mode. The algorithm for the general case is only good
for 0.8388 ulps, so this is sufficient (but it loses slightly on i386 --
then extra precision gives 0.5032 ulps for the general case).
While investigating this, I noticed that optimizing the usual case by
falling into a middle case involving a simple polynomial evaluation
(return x-x*x/2 instead of x here) is not such a good idea since it
gives an enormous pessimization of tinier args on machines for which
denormals are slow. Float x*x/2 is denormal when |x| ~< 2**-64 and
x*x/2 is evaluated in float precision, so it can easily be denormal
for normal x. This is even more interesting for general polynomial
evaluations. Multiplying out large powers of x is normally a good
optimization since it reduces dependencies, but it creates denormals
starting with quite large x.
