MFC r343826, r346698, r349057-r349060, r349073-r349077, r349080-r349086, r349088,
r349091-r349097, r349115, r349119, r349130-r349132, r349143-r349145,
r349164-r349168, r349174, r349269-r34927

MFC r343826, r346698, r349057-r349060, r349073-r349077, r349080-r349086, r349088,
r349091-r349097, r349115, r349119, r349130-r349132, r349143-r349145,
r349164-r349168, r349174, r349269-r349273

r343826 by yuripv:
pwm.8: fix markup in synopsis, add -f description

r346698 by manu:
arm: allwinner: aw_pwm: compile it as module too

r349057:
Allow pwm(9) components to be selected individually, while 'device pwm'
still includes it all.

r349058:
In detach(), check for failure of bus_generic_detach(), only release
resources if they got allocated (because detach() gets called from attach()
to handle various failures), and delete the pwmbus child if it got created.

r349059:
Don't call pwmbus_attach_bus(), because it may not be present if this
driver is compiled into the kernel but pwmbus will be loaded as a module
when needed (and because of that, pwmbus_attach_bus() is going away in
the near future). Instead, just directly do what that function did:
register the fdt xfef handle, and attach the pwmbus.

r349060:
Handle failure to enable the clock or obtain its frequency.

r349073:
Do not include pwm.h here, it is purely a userland interface file containing
ioctl defintions for the pwmc driver. It is not part of the pwmbus interface.

r349074:
Move/rename the sys/pwm.h header file to dev/pwm/pwmc.h. The file contains
ioctl definitions and related datatypes that allow userland control of pwm
hardware via the pwmc device. The new name and location better reflects its
assocation with a single device driver.

r349075:
Remove pwmbus_attach_bus(), it no longer has any callers. Also remove a
couple prototypes for functions that never existed (and never will).

r349076:
Use device_delete_children() instead of a locally-rolled copy of it that
leaks the device-list memory.

r349077:
Add a missing #include. I suspect this used to get included via some header
pollution that was cleaned up recently, and this file got missed in the
cleanup because it's not attached to the build unless you specifically
request this device in a custom kernel config.

r349080:
Make pwmbus driver and devclass vars static; they're not mentioned in any
header file, so they can't be used outside this file anyway.

r349081:
Unwrap prototype lines so that return type and function name are on the
same line. No functional changes.

r349082:
Spell unsigned int as u_int and channel as chan; eliminates the need to wrap
some long lines.

r349083:
Give the aw_pwm driver a module version.

r349084:
Rename the channel_max method to channel_count, because that's what it's
returning. (If the channel count is 2, then the max channel number is 1.)

r349085:
Destroy the cdev on device detach. Also, make the driver and devclass
static, because nothing outside this file needs them.

r349086:
Restructure the pwm device hirearchy and interfaces.

The pwm and pwmbus interfaces were nearly identical, this merges them into a
single pwmbus interface. The pwmbus driver now implements the pwmbus
interface by simply passing all calls through to its parent (the hardware
driver). The channel_count method moves from pwm to pwmbus, and the
get_bus method is deleted (just no longer needed).

The net effect is that the interface for doing pwm stuff is now the same
regardless of whether you're a child of pwmbus, or some random driver
elsewhere in the hierarchy that is bypassing the pwmbus layer and is talking
directly to the hardware driver via cross-hierarchy connections established
using fdt data.

The pwmc driver is now a child of pwmbus, instead of being its sibling
(that's why the get_bus method is no longer needed; pwmc now gets the
device_t of the bus using device_get_parent()).

r349088:
Make pwm channel numbers unsigned.

r349091:
The pwm interface was replaced with pwmbus, include the right header file.

r349092:
Make channel number unsigned, and spell unsigned int u_int. This should
have been part of r349088.

r349093:
This code no longer uses fdt/ofw stuff, no need to include ofw headers.

r349094:
Add module makefiles for pwm.

r349095:
Split the dtb MODULES_EXTRA line to a series of += lines, making it easier
to maintain and keep in alphabetical order, and paving the way for adding
some other modules that aren't dtb-related.

r349096:
Add module makefiles for Texas Instruments ARM SoCs.

The natural place to look for them based on how other SoCs are organized
would be sys/modules/ti, but that's already taken. Drop a clue into
modules/ti/Makefile directing people to modules/arm_ti if they're looking
for ARM modules.

r349097:
Build SoC-specific modules with GENERIC for the SoCs that have them.

r349115:
Rename pwmbus.h to ofw_pwm.h, because after all the recent changes, there
is nothing left in the file that related to pwmbus at all. It just contains
prototypes for the functions implemented in dev/pwm.ofw_pwm.c, so name it
accordingly and fix the include protect wrappers to match.

A new pwmbus.h will be coming along in a future commit.

r349119:
Rework pwmbus and pwmc so that each child will handle a single PWM channel.

Previously, there was a pwmc instance for each instance of pwm hardware
regardless of how many pwm channels that hardware supported. Now there
will be a pwmc instance for each channel when the hardware supports
multiple channels. With a separate instance for each channel, we can have
"named channels" in userland by making devfs alias entries in /dev/pwm.

These changes add support for ivars to pwmbus, and use an ivar to track the
channel number for each child. It also adds support for hinted children.

In pwmc, the driver checks for a label hint, and if present, it's used to
create an alias for the cdev in /dev/pwm. It's not anticipated that hints
will be heavily used, but it's easy to do and allows quick ad-hoc creation
of named channels from userland by using kenv to create hint.pwmc.N.label=
hints. Upcoming changes will add FDT support, and most labels will
probably be specified that way.

r349130:
Add ofw_pwmbus to enumerate pwmbus devices on systems configured with fdt
data. Also, add fdt support to pwmc.

r349131:
Implement the ofw_bus_get_node method in aw_pwm(4) so that ofw_pwmbus can
find its metadata for instantiating children.

r349132:
Add back a const qualifier I somehow fumbled away between test-building
and committing recent changes.

r349143:
Put the pwmc cdev filenames under the pwm directory along with any label
names. I.e., everything related to pwm now goes in /dev/pwm. This will
make it easier for userland tools to turn an unqualified name into a fully
qualified pathname, whether it's the base pwmcX.Y name or a label name.

r349144:
Follow changes in the pwmc(4) driver in relation to device filenames.

The driver now names its cdev nodes pwmcX.Y where X is unit number and
Y is the channel within that unit. Change the default device name from
pwmc0 to pwmc0.0. The driver now puts cdev files and label aliases in
the /dev/pwm directory, so allow the user to provide unqualified names
with -f and automatically prepend the /dev/pwm part for them.

Update the examples in the manpage to show the new device name format
and location within /dev/pwm.

r349145:
Put periods at the ends of argument descriptions. Explain the relationship
between the period and duty arguments.

r349164:
Remove everything related to channels from the pwmc public interface, now
that there is a pwmc(4) instance per channel and the channel number is
maintained as a driver ivar rather than being passed in from userland.

r349165:
Explain the relationship between PWM hardware channels being controlled and
pwmc(4) device filenames. Also, use uppercase PWM when the term is being
used as an acronym, and expand the acronym where it's first used.

r349166:
Rearrange the argument checking and processing so that enable and disable
can be combined with configuring the period and duty cycle (the same ioctl
sets all 3 values at once, so there's no reason to require the user to run
the program twice to get all 3 things set).

r349167:
Oops, it seems I left out the word 'cycle', fix it.

r349168:
Add a pwmc(4) manpage.

r349174:
Handle labels specified with hints even on FDT systems. Hints are the
easiest thing for a user to control (via loader.conf or kenv+kldload), so
handle them in addition to any label specified via the FDT data.

r349269:
Some mundane tweaks and cleanups to help de-clutter the diffs of some
upcoming functional changes.

Add an ofw_compat_data table for probing compat strings, and use it to add
PNP data. Remove some stray semicolons at the end of macro definitions,
and add a PWM_LOCK_ASSERT macro to round out the usual suite. Move the
device_t and driver_methods structs to the end of the file. Tweak comments.

r349270:
Add support for the PWM(9) API. This allows configuring the pwm output using
pwm(9), but also maintains the historical sysctl config interface for
compatiblity with existing apps. The two config systems are not compatible
with each other; if you use both interfaces to change configurations you're
likely to end up with incorrect output or none at all.

r349271:
Catch up with recent changes in pwmbus(9). The pwm(9) and pwmbus(9)
interfaces were unified into pwmbus(9), and the PWMBUS_CHANNEL_MAX method
was renamed PWMBUS_CHANNEL_COUNT. The pwmbus_attach_bus() function just
went away completely. Also, fix a few typos such as s/is/if/.

r349272:
Do some general cleanup and light wordsmithing.

Sort methods alphabetically. Wrap long lines. Start sentences on a new
line. Remove contractions (not because it's a good idea, just to silence
igor). Add some explanation of the units for the period and duty arguments
and the convention for channel numbers.

r349273:
Add pwm to the armv7 GENERIC kernel, it's now used by TI and Allwinner.

show more ...

Add support for loader veriexec

Also sbin/veriexec for mac_veriexec

MFC r343281,344564-344568,344780,344784,345289,346070

Handle -DNO_ROOT for `make compat` in include/

Otherwise this step will fail on a Linux host due to missing "wheel" group

Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd

Handle -DNO_ROOT for `make compat` in include/

Otherwise this step will fail on a Linux host due to missing "wheel" group

Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D16841

show more ...

Install symlink for sys/nvpair.h in include/Makefile symlinks target

Noticed while fixing the install/sysroot situation for libnvpair and
libzfs_core- if one uses the symlinks target, libzfs_core.h

Install symlink for sys/nvpair.h in include/Makefile symlinks target

Noticed while fixing the install/sysroot situation for libnvpair and
libzfs_core- if one uses the symlinks target, libzfs_core.h is not
installed.

show more ...

Use INCS for non-sys/ libnvpair and libzfs_core includes

While nothing was wrong with libnvpair.h, libzfs_core.h was only guarded by
MK_CDDL rather than MK_CDDL && MK_ZFS. Rather than ugl'if'ying
in

Use INCS for non-sys/ libnvpair and libzfs_core includes

While nothing was wrong with libnvpair.h, libzfs_core.h was only guarded by
MK_CDDL rather than MK_CDDL && MK_ZFS. Rather than ugl'if'ying
include/Makefile to impose the extra restriction, just move the non-sys/
includes into INCS with the respect lib builds.

This has the added bonus of allowing third party packagers to try and split
these libs out of the FreeBSD-runtime package, if they are so inclined.

The sys/ include was left alone- generally userland libraries shouldn't
install kernel headers.

MFC after: 1 week

show more ...

Import the netdump client code.

This is a component of a system which lets the kernel dump core to
a remote host after a panic, rather than to a local storage device.
The server component is availab

Import the netdump client code.

This is a component of a system which lets the kernel dump core to
a remote host after a panic, rather than to a local storage device.
The server component is available in the ports tree. netdump is
particularly useful on diskless systems.

The netdump(4) man page contains some details describing the protocol.
Support for configuring netdump will be added to dumpon(8) in a future
commit. To use netdump, the kernel must have been compiled with the
NETDUMP option.

The initial revision of netdump was written by Darrell Anderson and
was integrated into Sandvine's OS, from which this version was derived.

Reviewed by: bdrewery, cem (earlier versions), julian, sbruno
MFC after: 1 month
X-MFC note: use a spare field in struct ifnet
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D15253

show more ...

Retire lmc(4)

This driver supports legacy, 32-bit PCI devices, and had an ambiguous
license. Supported devices were already reported to be rare in 2003
(when an earlier version of the driver was re

Retire lmc(4)

This driver supports legacy, 32-bit PCI devices, and had an ambiguous
license. Supported devices were already reported to be rare in 2003
(when an earlier version of the driver was removed in r123201).

Reviewed by: rgrimes
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15245

show more ...

Add the "TCP Blackbox Recorder" which we discussed at the developer
summits at BSDCan and BSDCam in 2017.

The TCP Blackbox Recorder allows you to capture events on a TCP connection
in a ring buffer.

Add the "TCP Blackbox Recorder" which we discussed at the developer
summits at BSDCan and BSDCam in 2017.

The TCP Blackbox Recorder allows you to capture events on a TCP connection
in a ring buffer. It stores metadata with the event. It optionally stores
the TCP header associated with an event (if the event is associated with a
packet) and also optionally stores information on the sockets.

It supports setting a log ID on a TCP connection and using this to correlate
multiple connections that share a common log ID.

You can log connections in different modes. If you are doing a coordinated
test with a particular connection, you may tell the system to put it in
mode 4 (continuous dump). Or, if you just want to monitor for errors, you
can put it in mode 1 (ring buffer) and dump all the ring buffers associated
with the connection ID when we receive an error signal for that connection
ID. You can set a default mode that will be applied to a particular ratio
of incoming connections. You can also manually set a mode using a socket
option.

This commit includes only basic probes. rrs@ has added quite an abundance
of probes in his TCP development work. He plans to commit those soon.

There are user-space programs which we plan to commit as ports. These read
the data from the log device and output pcapng files, and then let you
analyze the data (and metadata) in the pcapng files.

Reviewed by: gnn (previous version)
Obtained from: Netflix, Inc.
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D11085

show more ...

Add kernel and userspace code to dump the firmware state of supported
ConnectX-4/5 devices in mlx5core.

The dump is obtained by reading a predefined register map from the
non-destructive crspace, ac

Add kernel and userspace code to dump the firmware state of supported
ConnectX-4/5 devices in mlx5core.

The dump is obtained by reading a predefined register map from the
non-destructive crspace, accessible by the vendor-specific PCIe
capability (VSC). The dump is stored in preallocated kernel memory and
managed by the mlx5tool(8), which communicates with the driver using a
character device node.

The utility allows to store the dump in format
<address> <value>
into a file, to reset the dump content, and to manually initiate the
dump.

A call to mlx5_fwdump() should be added at the places where a dump
must be fetched automatically. The most likely place is right before a
firmware reset request.

Submitted by: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers from both the kernel and as
userland daemons are possible, though much of that functionality will
come later.

Some of the CAM integration isn't complete (there are sleeps in the
device probe state machine, for example), but those minor issues can
be improved in-tree more easily than out of tree and shouldn't gate
progress on other fronts. Appologies to reviews if specific items
have been overlooked.

Submitted by: Ilya Bakulin
Reviewed by: emaste, imp, mav, adrian, ian
Differential Review: https://reviews.freebsd.org/D4761

merge with first commit, various compile hacks.

show more ...

Utilize SYSROOT from r320119 in places where DESTDIR may be wanting WORLDTMP.

Since buildenv exports SYSROOT all of these uses will now look in
WORLDTMP by default.

sys/boot/efi/loader/Makefile

Utilize SYSROOT from r320119 in places where DESTDIR may be wanting WORLDTMP.

Since buildenv exports SYSROOT all of these uses will now look in
WORLDTMP by default.

sys/boot/efi/loader/Makefile
A LIBSTAND hack is no longer required for buildenv.

MFC after: 2 weeks
Sponsored by: Dell EMC Isilon

show more ...

Remove the NATM framework including the en(4), fatm(4), hatm(4), and
patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the cas

Remove the NATM framework including the en(4), fatm(4), hatm(4), and
patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).

With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.

Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.

Reviewed by: philip
Approved by: harti

show more ...

- Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition

- Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)

Of these "partitions", only the enhanced user data area one actually
slices the user data area partition and, thus, gets handled with the
help of geom_flashmap(4). The other types of partitions have address
space independent from the default partition and need to be switched
to via CMD6 (SWITCH), i. e. constitute a set of additional "disks".

The second kind of these "partitions" doesn't fit that well into the
design of mmc(4) and mmcsd(4). I've decided to let mmcsd(4) hook all
of these "partitions" up as disk(9)'s (except for the RPMB partition
as it didn't seem to make much sense to be able to put a file-system
there and may require authentication; therefore, RPMB partitions are
solely accessible via the newly added IOCTL interface currently; see
also below). This approach for one resulted in cleaner code. Second,
it retains the notion of mmcsd(4) children corresponding to a single
physical device each. With the addition of some layering violations,
it also would have been possible for mmc(4) to add separate mmcsd(4)
instances with one disk each for all of these "partitions", however.
Still, both mmc(4) and mmcsd(4) share some common code now e. g. for
issuing CMD6, which has been factored out into mmc_subr.c.

Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.

CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.

- Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications. However, quite some work is
left to be done in this regard; all other R1B-type commands done by
the MMC layer also should be followed by a SEND_STATUS (CMD13), the
erase timeout calculations/handling as documented in specifications
are entirely ignored so far, the MMC layer doesn't provide timeouts
applicable up to the bridge drivers and at least sdhci(4) currently
is hardcoding 1 s as timeout for all command types unconditionally.
Let alone already available return codes often not being checked in
the MMC layer ...

- Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter will be added to ports as sysutils/mmc-utils in
a bit. Among others, the `mmc` tool of the GNU mmc-utils allows for
partitioning eMMC devices (tested working).

- For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.

- Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.

- In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.

OKed by: imp
Submitted by: ian (mmc_switch_status() implementation)

show more ...

Convert include over to SRCTOP

Use SRCTOP in place of .CURDIR/.. as appropriate. The hand-crafted
relative paths for the "links" option remain, though, since those are
relative to /usr/include/sys/<

Convert include over to SRCTOP

Use SRCTOP in place of .CURDIR/.. as appropriate. The hand-crafted
relative paths for the "links" option remain, though, since those are
relative to /usr/include/sys/<blah> not to the source tree.

Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)

show more ...

hyperv: Allow userland to ro-mmap reference TSC page

This paves way to implement VDSO for the enlightened time counter.

Reviewed by: kib
MFC after: 1 week
Sponsored by: Microsoft
Differential Revis

hyperv: Allow userland to ro-mmap reference TSC page

This paves way to implement VDSO for the enlightened time counter.

Reviewed by: kib
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8768

show more ...

Create the /usr/lib/include symlink as relative.

This ugly code is done to avoid assuming LIBDIR is 2 components
deep.

Reported by: jhb

hyperv/vss: Add driver and tools for VSS

VSS stands for "Volume Shadow Copy Service". Unlike virtual machine
snapshot, it only takes snapshot for the virtual disks, so both
filesystem and applicati

hyperv/vss: Add driver and tools for VSS

VSS stands for "Volume Shadow Copy Service". Unlike virtual machine
snapshot, it only takes snapshot for the virtual disks, so both
filesystem and applications have to aware of it, and cooperate the
whole VSS process.

This driver exposes two device files to the userland:

/dev/hv_fsvss_dev

Normally userland programs should _not_ mess with this device file.
It is currently used by the hv_vss_daemon(8), which freezes and
thaws the filesystem. NOTE: currently only UFS is supported, if
the system mounts _any_ other filesystems, the hv_vss_daemon(8)
will veto the VSS process.

If hv_vss_daemon(8) was disabled, then this device file must be
opened, and proper ioctls must be issued to keep the VSS working.

/dev/hv_appvss_dev

Userland application can opened this device file to receive the
VSS freeze notification, hold the VSS for a while (mainly to flush
application data to filesystem), release the VSS process, and
receive the VSS thaw notification i.e. applications can run again.

The VSS will still work, even if this device file is not opened.
However, only filesystem consistency is promised, if this device
file is not opened or is not operated properly.

hv_vss_daemon(8) is started by devd(8) by default. It can be disabled
by editting /etc/devd/hyperv.conf.

Submitted by: Hongjiang Zhang <honzhan microsoft com>
Reviewed by: kib, mckusick
MFC after: 3 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8224

show more ...

Re-apply change 306811 or alternatively, revert change 307385.

Revert change 306811 so that the change can be re-done using
svn copy instead of svn move. This to preserve history on
the originals headers as well.

install header files required development with libzfs_core

libzfs_core provides a rather limited but committed (stable) interface
for working with ZFS. We install libzfs_core shared library but we

install header files required development with libzfs_core

libzfs_core provides a rather limited but committed (stable) interface
for working with ZFS. We install libzfs_core shared library but we do
not install header files required for developing programs that use
the library. This change is to install the required header files
libzfs_core.h, libnvpair.h and sys/nvpair.h.

The headers are installed into the same locations as on illumos.

Reviewed by: mav, markj
Differential Revision: https://reviews.freebsd.org/D8005

show more ...

In order to allow mkimg(1) (and other tools) to become a build tool
that can be compiled on various OSes (including on older versions
of FreeBSD), make it possible to have it include the partitioning

In order to allow mkimg(1) (and other tools) to become a build tool
that can be compiled on various OSes (including on older versions
of FreeBSD), make it possible to have it include the partitioning
scheme definitions without pulling in FreeBSD specifics.
In particular this means:
o move the scheme definitions iand related defines to header files
under sys/disk,
o make them (more) portable by using uint#_t (where applicable)
and renaming defines so that they at least have a good prefix,
o make the new headers stand-alone so that they don't need FreeBSD
definitions, like struct uuid(*)
o keep the original headers for compatibility, but rewrite them to
get the scheme definitions from <sys/disk/$scheme.h>.

(*) since UUID/GUID type definitions are non-portable and the GPT
scheme uses them, make it possible to have the scheme definitions
use an external type by allowing consumers of the header to set
GPT_UUID_TYPE. When GPT_UUID_TYPE has not been defined, the header
will use it's own type definition, which is the same as struct uuid.
The gpt_uuid_t typedef is created to abstract the details and allows
consumers to refer to a single type.

There is not conflict between the partitioning scheme headers and
what is defined in them. All headers can be included in the same
source files.

Note: consumers of the old headers have not been changed yet. Such
will be done if and when needed/beneficial.

Reviewed by: imp, jhb
MFC after: 1 month
Sponsored by: Bracket Computing

show more ...

Add evdev protocol implementation

evdev is a generic input event interface compatible with Linux
evdev API at ioctl level. It allows using unmodified (apart from
header name) input evdev drivers in

Add evdev protocol implementation

evdev is a generic input event interface compatible with Linux
evdev API at ioctl level. It allows using unmodified (apart from
header name) input evdev drivers in Xorg, Wayland, Qt.

This commit has only generic kernel API. evdev support for individual
hardware drivers like ukbd, ums, atkbd, etc. will be committed later.

Project was started by Jakub Klama as part of GSoC 2014. Jakub's
evdev implementation was later used as a base, updated and finished
by Vladimir Kondratiev.

Submitted by: Vladimir Kondratiev <[email protected]>
Reviewed by: adrian, hans
Differential Revision: https://reviews.freebsd.org/D6998

show more ...

Commit the bits of nda that were missed. This should fix the build.

Approved by: re@

Reviewed by: rpaulo
Approved by: rpaulo
Obtained from: NetBSD external/bsd/blacklist @ 20160409
Relnotes: YES
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/

Reviewed by: rpaulo
Approved by: rpaulo
Obtained from: NetBSD external/bsd/blacklist @ 20160409
Relnotes: YES
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5912

show more ...

WITH_META_MODE: Disable cookie handling for include installation.

Using a cookie with meta mode causes it to *not rerun* (as normal make
does) unless the command changes or filemon-detected files ch

WITH_META_MODE: Disable cookie handling for include installation.

Using a cookie with meta mode causes it to *not rerun* (as normal make
does) unless the command changes or filemon-detected files change.

After all of the work done here it turns out that skipping installation
is dangerous since the install commands use <dir>/*.h. The actual build
command is not changing but the files installed are changing by the mere
act of adding a new header into the source tree. Thus we cannot safely
use meta mode logic here. It must always rerun and install the headers.
The install -C flag at least prevents churning timestamps when
installing a header that was already present.

Sponsored by: EMC / Isilon Storage Division

show more ...