Our dc(1) has never correctly calculated remainders with fractional inputs.
Both bmod and bdivmod seem to have copy/pasted code from bdiv, which results
in the remainder having the wrong output scale.
PR: 162495
Reported by: anonymous
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D13390
This provides a nice wrarpper around the XPT_PATH_INQ ccb creation and
calling.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13387
kernel scheduler is stopped, replace the by hand calling of
xpt_polled_action() with it.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13388
For mails which has a body not respecting RFC2822 (which often happen with
crontabs) try to split by words finding the last space before 1000's character
If no spaces are found then consider the mail to be malformed anyway
PR: 208261
Currently each call to telldir() requires a malloc and adds an entry to a
linked list which must be traversed on future telldir(), seekdir(),
closedir(), and readdir() calls. Applications that call telldir() for every
directory entry incur O(n^2) behavior in readdir() and O(n) in telldir() and
closedir().
This optimization eliminates the malloc() and linked list in most cases by
packing the relevant information into a single long. On 64-bit architectures
msdosfs, NFS, tmpfs, UFS, and ZFS can all use the packed representation. On
32-bit architectures msdosfs, NFS, and UFS can use the packed
representation, but ZFS and tmpfs can only use it for about the first 128
files per directory. Memory savings is about 50 bytes per telldir(3) call.
Speedup for telldir()-heavy directory traversals is about 20-30x for one
million files per directory.
Reviewed by: kib, mav, mckusick
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13385
allocated memory when it returns early.
Free the memory associated with the variables full_programe, bin_dirs,
prog_dirs, and prefix_dirs when the function returns early.
Submitted by: Tom Rix <trix@juniper.net>
Reviewed by: jhibbits, emaste
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9691
matching failure.
According to the Open Group documentation for fwscanf:
"Upon successful completion, these functions shall return the number of
successfully matched and assigned input items; this number can be zero in
the event of an early matching failure."
Without this change, fwscanf would return EOF in the case of an early
matching failure, instead of the proper return value of 0.
This change aligns fwscanf(3) with the implementation in fscanf(3).
PR: 202240
Submitted by: rajendra.sy@gmail.com
Reviewed by: jhb, cem
Approved by: sjg (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13288
adagetparams contains a sign-extension error that will cause the sector
count to be incorrectly calculated for ATA disks of >=1TiB that still use
CHS addressing. Disks using LBA48 addressing are unaffected.
Reported by: Coverity
CID: 1007296
Reviewed by: ken
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13198
Rather than relying on 'cluster' existing in the context they're used in,
use the argument name.
Differential Revision: https://reviews.freebsd.org/D12931
This change was made to allow zstd(1) to be a dropin replacement for gzip(1) and
friends, allowing easy integration, in particular with newsyslog(8). At the
price of having a zstd(1) command which by default behaves differently than what
upstream default, confusing users.
newsyslog(8) has been adapted to now be more flexible in what it accepts as
compression program, so we can switch back zstd(1) to its default behaviour
Reported by: many
have a semantic different than the traditional gzip(1)
This is done to allow to use zstd(1) as a compression tool without
having to patch it to change its default behavior.
I did a complete buildworld and test... with the program disconnected
from the tree. Revert the change for now.
(this keeps the change to .arclint which is still correct)
Wearing: my pointhat
Summary:
As in /dev/fb, allow the framebuffer driver to override the default memattr for
mmap(2). This is analogous to the change in 306555.
Reviewed By: ray
Differential Revision: https://reviews.freebsd.org/D13331
Summary:
Some architectures (powerpc Book-E) have a vm_paddr_t larger than intptr_t.
Casting from the intptr_t to vm_paddr_t causes sign extension, leading to a
potentially invalid address.
This was seen when running X on a PowerPC P1022 machine, which mapped the
backing framebuffer at 0xc1800000. When mmap()d by X, this yielded an invalid
address of 0xffffffffc1800000, or, as the hardware would see it, 0xfc1800000.
Reviewed By: ray
Differential Revision: https://reviews.freebsd.org/D13332
currently harmless for AC_UNIT_ATTENTION event (cam_periph_async does
nothing with them), it's still in error because if it were to start in
the future, it would be done twice.
Sponsored by: Netflix
Also document IEEE Std 1003.1-2008, 2013 edition in mdoc(7) (as well as the
2016 edition).
Submitted by: Yuri Pankov
Reviewed by: bjk
Differential Revision: https://reviews.freebsd.org/D13349
change. Now on FreeBSD and NetBSD if _STANDALONE is defined, we
include the kernel version with alloances for the quirky differences
between the two.
Sponsored by: Netflix
sinovoip-bpi-m3.dts was disconnected from the build in r324822. Since then,
a CCU driver has been added and several other changes have been made to
make us compatible with upstream DTS for this board.
Add links for older DTB that might be used: our u-boot port was expecting
sinovoip-bpi-m3.dtb up until ports r455629, and our u-boot will not be
switching to the upstream name (sun8i-a83t-bananapi-m3) quite yet.
Discussed with: manu
Previously we set the csum_l3 flag for IPv4 and IPv6, but only IPv4
should have header checksumming applied.
Prompted by Linux commit fa6d7cb5d76cf0467c61420fc9238045aedfd379.
Reviewed by: bz
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13366
