man filesystems: fix more xrefs after move to s4

Fixes: 1a720cbec513
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1282

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

devfs.rules: Do not expose "log" in the default devfs rules.

/etc/rc.d/jail no longer creates /dev/log as a symbolic link since
commit 84b354cb9ab61224713c159b1484e8f070fd37be.

PR: 228351
Reviewed

devfs.rules: Do not expose "log" in the default devfs rules.

/etc/rc.d/jail no longer creates /dev/log as a symbolic link since
commit 84b354cb9ab61224713c159b1484e8f070fd37be.

PR: 228351
Reviewed by: jamie, mark
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D34563

show more ...

devfs.rules: Correctly unhide pf in vnet jails

Revision 9e9be081d8 introduced a new devfs rule devfsrules_jail_vnet. It
includes rule devfsrules_jail which include other rules. Unfortunately
devfs c

devfs.rules: Correctly unhide pf in vnet jails

Revision 9e9be081d8 introduced a new devfs rule devfsrules_jail_vnet. It
includes rule devfsrules_jail which include other rules. Unfortunately
devfs could not recursively parse the action include and thus
devfsrules_jail_vnet will expose all nodes.

PR: 255660
Reviewed by: kp
Obtained from: Gijs Peskens <gijs@peskens.net>
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D32814

show more ...

devfs.rules: unhide pf in vnet jails

/dev/pf is usable in vnet jails, so don't hide the node there.

We shouldn't expose /dev/pf in regular jails, as that gives them control over
the host (or parent

devfs.rules: unhide pf in vnet jails

/dev/pf is usable in vnet jails, so don't hide the node there.

We shouldn't expose /dev/pf in regular jails, as that gives them control over
the host (or parent vnet jail) firewall.

Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D26537

show more ...

Move all devfs related files to sbin/devfs/

This is related to pkgbase as it uses CONFS to properly tag these as config
files.

Approved by: will (mentor)
Differential Revision: https://reviews.free

Move all devfs related files to sbin/devfs/

This is related to pkgbase as it uses CONFS to properly tag these as config
files.

Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16785

show more ...

Allow mounting FUSE filesystems in jails

Reviewed by: jamie
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16371

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

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

show more ...

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 suffi

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.

show more ...