<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/etc/defaults/devfs.rules, branch release/5.4.0</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src/atom?h=release%2F5.4.0</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src/atom?h=release%2F5.4.0'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/'/>
<updated>2004-01-22T20:53:15Z</updated>
<entry>
<title>If we're going to "add path 'fd/*' unhide", it only makes</title>
<updated>2004-01-22T20:53:15Z</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2004-01-22T20:53:15Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=7338182f910eaf85d1e60170c65a5da17f001f8f'/>
<id>urn:sha1:7338182f910eaf85d1e60170c65a5da17f001f8f</id>
<content type='text'>
sense to "add path fd unhide" first.

Requested by: mtm
Approved by: rwatson (mentor)
</content>
</entry>
<entry>
<title>As far as we know, there is no reason to not expose /dev/crypto in</title>
<updated>2003-09-26T10:32:21Z</updated>
<author>
<name>Poul-Henning Kamp</name>
<email>phk@FreeBSD.org</email>
</author>
<published>2003-09-26T10:32:21Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=5e27a46ce91a99fcb44e70c2b925adf9fa433510'/>
<id>urn:sha1:5e27a46ce91a99fcb44e70c2b925adf9fa433510</id>
<content type='text'>
jails so code in there can take advantage of hardware assisted
crypto.
</content>
</entry>
<entry>
<title>Add a general mechanism for creating and applying</title>
<updated>2003-08-20T06:15:18Z</updated>
<author>
<name>Mike Makonnen</name>
<email>mtm@FreeBSD.org</email>
</author>
<published>2003-08-20T06:15:18Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src/commit/?id=130112f793bd03ae70f02652a3110abcb6ec6f01'/>
<id>urn:sha1:130112f793bd03ae70f02652a3110abcb6ec6f01</id>
<content type='text'>
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.
</content>
</entry>
</feed>
