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
section. This removes stuff that doesn't really belong there,
and simplifies examples for the basic operations.
Reviewed by: wblock@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3198
CloudABI purely operates on file descriptor rights (CAP_*). File
descriptor access modes (O_ACCMODE) are emulated on top of rights.
Instead of accepting the traditional flags argument, file_open() copies
in an fdstat_t object that contains the initial rights the descriptor
should have, but also file descriptor flags that should persist after
opening (APPEND, NONBLOCK, *SYNC). Only flags that don't persist (EXCL,
TRUNC, CREAT, DIRECTORY) are passed in as an argument.
file_open() first converts the rights, the persistent flags and the
non-persistent flags to fflags. It then calls into vn_open(). If
successful, it installs the file descriptor with the requested
rights, trimming off rights that don't apply to the type of
the file that has been opened.
Unlike kern_openat(), this function does not support /dev/fd/*. I can't
think of a reason why we need to support this for CloudABI.
Obtained from: https://github.com/NuxiNL/freebsd
Differential Revision: https://reviews.freebsd.org/D3235
BROKEN NFS SERVER OR MIDDLEWARE: Certain WAN "accelerators" attempt to cache
NFS GETATTR traffic, but actually corrupt it (e.g., responding to requests
with attributes for totally different files).
Warn very verbosely when this is detected. Linux' NFS client has a similar
warning.
Adds a sysctl/tunable (vfs.nfs.fileid_maxwarnings) to configure the quantity
of warnings; default to 10. (Zero disables; -1 is unlimited.)
Adds a failpoint to aid in validating the warning / behavior with a
non-broken server. Use something like:
sysctl 'debug.fail_point.nfscl_force_fileid_warning=10%return(1)'
Reviewed by: rmacklem
Approved by: markj (mentor)
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3304
At this point IMMED flag is translated to MNT_NOWAIT flag of VOP_FSYNC(),
hoping that file system implements that (ZFS seems doesn't).
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
tightening sanity check of the input. [1]
While I'm there also replace ed(1) with red(1) because we do
not need the unrestricted functionality. [2]
Obtained from: Bitrig [1], DragonFly [2]
Security: CVE-2015-1418 [1]
Before this change SYNCHRONIZE CACHE commands were executed exclusively,
as if they had ORDERED tag. But looking through SCSI specs I've found
no any reason to be so strict. For reads this ordering seems pointless.
For writes it looks less obvious, so I left ordering against preceeding
write commands, while following ones are no longer required to wait.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
If the resulting argument is longer than MAXPATHLEN, realloc() was called to
extend the space, but the new pointer was not correctly stored.
Different from what OpenBSD has done, rewrite brace_subst() to calculate the
necessary space first and realloc() at most once.
As before, the e_len fields are not updated in case of a realloc.
Therefore, a following long argument will do another realloc.
PR: 201750
MFC after: 1 week
is detaching.
This mostly fixes a panic - the reset path shouldn't run whilst
the NIC is being torn down.
It's not locked, so it's "mostly" ok, but most of the rest of
the driver doesn't read sc->invalid with sensible locking. Grr.
The real solution is to cleanly tear down taskqueues in the detach/suspend
phase, but ..
