Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Unhide /dev/zfs in devfsrules_jail.

The /dev/zfs device is required for managing jailed ZFS datasets.

Discussed with: pjd, jamie
MFC after: 1 week

Expose "log" in the default devfs rules. /etc/rc.d/jail creates /dev/log
as a symbolic link.

PR: conf/160711
Submitted by: Jase Thew
Approved by: re (kib)
MFC after: 1 week

Expose the upper 256 ptys in the default devfs rules. I should have updated
this when expanding the old pty(4) driver to use 512 ptys by default. This
is more important for 7.x.

MFC after: 1 week

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:

- Improved driver model:

The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.

If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.

- Improved hotplugging:

With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).

The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.

- Improved performance:

One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.

Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.

Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan

Add pts/pty to the un-hidden devices for logins. This un-breaks
logins to jailed environments when the system is using PTS style
ptys (kern.pts.enable=1).

Discussed with: rwatson
MFc after: 1 week

Correct two typos in comments.

If we're going to "add path 'fd/*' unhide", it only makes
sense to "add path fd unhide" first.

Requested by: mtm
Approved by: rwatson (mentor)

As far as we know, there is no reason to not expose /dev/crypto in
jails so code in there can take advantage of hardware assisted
crypto.

Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.