LLVM PR 24343. This fixes the graphics/png build on i386, which
otherwise failed during its tests because of floating point exceptions,
leading to >5000 skipped other ports.
reference types defined in the kernel. Otherwise dtrace(1) expects to find
CTF definitions for all referenced types, which is not very reasonable
when it is being used in a build environment. This was previously worked
around by adding "-x nolibs" to dtrace -h or -G invocations, but as of
r283025, dtrace(1) actually handles dependencies properly, so this is no
longer necessary.
- Remove "pragma ident" directives from DTrace libraries, as they're being
phased out upstream as well.
Submitted by: Krister Johansen <Krister.Johansen@isilon.com> [1]
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
order, but IN_ZERONET and IN_LOOPBACK expect it in host order.
Submitted by: Tao Liu <Tao.Liu@isilon.com>
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
Main problem there was PIO mode support, that required KVA mapping.
Handle that case using recently added pmap_quick_enter_page(9) KPI,
mapping data pages to KVA one at a time.
with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix
reverted. We can do direct processing when g_io_check() does not need
to perform transient remapping of the bio, otherwise the thread has to
sleep.
Reviewed by: mav (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
use was removed in r173592 (Nov 2007), yet Xen PV bits continued
referencing the privatespace structure, and were removed in r282274
(Apr 2015).
Discussed with: jhb
Sponsored by: The FreeBSD Foundation
is taken to match the geometry and only when the geometry is max'd
out, is the actual recorded size taken.
Note that qemu has the same logic for the fixed VHD format. However
that is known to conflict with Microsoft Azure, where the recorded
size of the image is what counts.
Pointed out by: gjb@
The ftdi chip itself has a "get bitmode" command that doesn't actually
return the current bitmode, just a snapshot of the gpio lines. The chip
apparently has no way to provide the current bitmode.
This implements the functionality at the driver level. The driver starts
out assuming the chip is in UART mode (which it will be, coming out of
reset) and keeps track of every successful set-bitmode operation so that
it can always return the current mode with UFTDIIOC_GET_BITMODE.
especially useful now that libc's open() always calls openat(). While here,
fix a few other things:
- Decode the mode argument passed to access(), eaccess(), and faccessat().
- Decode the atfd paramete to pretty-print AT_FDCWD.
- Decode the special AT_* flags used with some of the *at() system calls.
- Decode arguments for fchmod(), lchmod(), fchown(), lchown(), eaccess(),
and futimens().
- Decode both of the timeval structures passed to futimes() instead of just
the first one.
The expected semantic is to have misc. data, e.g. CPU bitmaps, visible
in the BSP after smp_started is written by the last started AP, which
formally requires acquire barrier on the load. The change is mostly
nop due to the ordered behaviour of the x86 CPUs.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
so we cannot access it anymore. Setting an error later lead to memory
corruption.
Assert that crypto_dispatch() was successful. It can fail only if we pass a
bogus crypto request, which is a bug in the program, not a runtime condition.
PR: 199705
Submitted by: luke.tw
Reviewed by: emaste
MFC after: 3 days
use vtophys() directly instead of vtomach() and retire the no-longer-used
headers <machine/xenfunc.h> and <machine/xenvar.h>.
Reported by: bde (stale bits in <machine/xenfunc.h>)
Reviewed by: royger (earlier version)
Differential Revision: https://reviews.freebsd.org/D3266
mappings as if MAP_SHARED was always present since in general MAP_PRIVATE
is not permitted for character devices. However, there is one exception
in that MAP_PRIVATE mappings are permitted for /dev/zero.
Only require a writable file descriptor (FWRITE) for shared, writable
mappings of character devices. vm_mmap_cdev() will reject any private
mappings for other devices.
Reviewed by: kib
Reported by: sbruno (broke qemu cross-builds), peter
Differential Revision: https://reviews.freebsd.org/D3316
There have been .local version of each for user modifications for some time
This allows users to receive future updates to these files
PR: 183765
Submitted by: Bertram Scharpf, Nikolai Lifanov (patch)
Reviewed by: dteske, loos, eadler
Approved by: bapt (mentor)
MFC after: 1 month
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D3176
