<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/dev/tdfx/tdfx_linux.c, branch releng/14.3</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>tdfx: Handle errors from copyin() and copyout()</title>
<updated>2024-01-04T13:42:13+00:00</updated>
<author>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</author>
<published>2023-12-26T23:59:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9fcacb1e6869eec4b8de67e072c64036d074249b'/>
<id>9fcacb1e6869eec4b8de67e072c64036d074249b</id>
<content type='text'>
This is in preparation for annotating copyin() and related functions
with __result_use_check.

MFC after:	1 week

(cherry picked from commit 2873d841f81cdc205135370875d3d71a3402e90a)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is in preparation for annotating copyin() and related functions
with __result_use_check.

MFC after:	1 week

(cherry picked from commit 2873d841f81cdc205135370875d3d71a3402e90a)
</pre>
</div>
</content>
</entry>
<entry>
<title>sys: Remove $FreeBSD$: one-line .c pattern</title>
<updated>2023-08-16T17:54:36+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-08-16T17:54:36+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=685dc743dc3b5645e34836464128e1c0558b404b'/>
<id>685dc743dc3b5645e34836464128e1c0558b404b</id>
<content type='text'>
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
</pre>
</div>
</content>
</entry>
<entry>
<title>spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD</title>
<updated>2023-05-12T16:44:03+00:00</updated>
<author>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</author>
<published>2023-05-10T15:40:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4d846d260e2b9a3d4d0a701462568268cbfe7a5b'/>
<id>4d846d260e2b9a3d4d0a701462568268cbfe7a5b</id>
<content type='text'>
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert remaining cap_rights_init users to cap_rights_init_one</title>
<updated>2021-01-12T13:16:10+00:00</updated>
<author>
<name>Mateusz Guzik</name>
<email>mjg@FreeBSD.org</email>
</author>
<published>2021-01-12T12:11:26+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=6b3a9a0f3d2cd66145e89fdd8d07cb33a9963e8f'/>
<id>6b3a9a0f3d2cd66145e89fdd8d07cb33a9963e8f</id>
<content type='text'>
semantic patch:

@@

expression rights, r;

@@

- cap_rights_init(&amp;rights, r)
+ cap_rights_init_one(&amp;rights, r)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
semantic patch:

@@

expression rights, r;

@@

- cap_rights_init(&amp;rights, r)
+ cap_rights_init_one(&amp;rights, r)
</pre>
</div>
</content>
</entry>
<entry>
<title>sys/dev: further adoption of SPDX licensing ID tags.</title>
<updated>2017-11-27T14:52:40+00:00</updated>
<author>
<name>Pedro F. Giffuni</name>
<email>pfg@FreeBSD.org</email>
</author>
<published>2017-11-27T14:52:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=718cf2ccb9956613756ab15d7a0e28f2c8e91cab'/>
<id>718cf2ccb9956613756ab15d7a0e28f2c8e91cab</id>
<content type='text'>
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
</pre>
</div>
</content>
</entry>
<entry>
<title>Update kernel inclusions of capability.h to use capsicum.h instead; some</title>
<updated>2014-03-16T10:55:57+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2014-03-16T10:55:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4a14441044e0bdb55c81010ea92b24d87c25ee56'/>
<id>4a14441044e0bdb55c81010ea92b24d87c25ee56</id>
<content type='text'>
further refinement is required as some device drivers intended to be
portable over FreeBSD versions rely on __FreeBSD_version to decide whether
to include capability.h.

MFC after:	3 weeks
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
further refinement is required as some device drivers intended to be
portable over FreeBSD versions rely on __FreeBSD_version to decide whether
to include capability.h.

MFC after:	3 weeks
</pre>
</div>
</content>
</entry>
<entry>
<title>Change the cap_rights_t type from uint64_t to a structure that we can extend</title>
<updated>2013-09-05T00:09:56+00:00</updated>
<author>
<name>Pawel Jakub Dawidek</name>
<email>pjd@FreeBSD.org</email>
</author>
<published>2013-09-05T00:09:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=7008be5bd7341259037f383434a72960413cfeb8'/>
<id>7008be5bd7341259037f383434a72960413cfeb8</id>
<content type='text'>
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

	struct cap_rights {
		uint64_t	cr_rights[CAP_RIGHTS_VERSION + 2];
	};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

	#define	CAP_PDKILL	CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

	#define	CAP_LOOKUP	CAPRIGHT(0, 0x0000000000000400ULL)
	#define	CAP_FCHMOD	CAPRIGHT(0, 0x0000000000002000ULL)

	#define	CAP_FCHMODAT	(CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

	cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
	void cap_rights_set(cap_rights_t *rights, ...);
	void cap_rights_clear(cap_rights_t *rights, ...);
	bool cap_rights_is_set(const cap_rights_t *rights, ...);

	bool cap_rights_is_valid(const cap_rights_t *rights);
	void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
	void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
	bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

	cap_rights_t rights;

	cap_rights_init(&amp;rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

	#define	cap_rights_set(rights, ...)				\
		__cap_rights_set((rights), __VA_ARGS__, 0ULL)
	void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

	cap_rights_init(&amp;rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by:	The FreeBSD Foundation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in the future in a backward compatible (API and ABI) way.

The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.

The structure definition looks like this:

	struct cap_rights {
		uint64_t	cr_rights[CAP_RIGHTS_VERSION + 2];
	};

The initial CAP_RIGHTS_VERSION is 0.

The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.

The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.

To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.

	#define	CAP_PDKILL	CAPRIGHT(1, 0x0000000000000800ULL)

We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:

	#define	CAP_LOOKUP	CAPRIGHT(0, 0x0000000000000400ULL)
	#define	CAP_FCHMOD	CAPRIGHT(0, 0x0000000000002000ULL)

	#define	CAP_FCHMODAT	(CAP_FCHMOD | CAP_LOOKUP)

There is new API to manage the new cap_rights_t structure:

	cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
	void cap_rights_set(cap_rights_t *rights, ...);
	void cap_rights_clear(cap_rights_t *rights, ...);
	bool cap_rights_is_set(const cap_rights_t *rights, ...);

	bool cap_rights_is_valid(const cap_rights_t *rights);
	void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
	void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
	bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);

Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:

	cap_rights_t rights;

	cap_rights_init(&amp;rights, CAP_READ, CAP_WRITE, CAP_FSTAT);

There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:

	#define	cap_rights_set(rights, ...)				\
		__cap_rights_set((rights), __VA_ARGS__, 0ULL)
	void __cap_rights_set(cap_rights_t *rights, ...);

Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:

	cap_rights_init(&amp;rights, CAP_LOOKUP | CAP_PDKILL);

Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.

This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.

Sponsored by:	The FreeBSD Foundation
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert previous commit...</title>
<updated>2012-10-10T08:36:38+00:00</updated>
<author>
<name>Kevin Lo</name>
<email>kevlo@FreeBSD.org</email>
</author>
<published>2012-10-10T08:36:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9823d52705ad71f19ef2205aa729547ac396e3eb'/>
<id>9823d52705ad71f19ef2205aa729547ac396e3eb</id>
<content type='text'>
Pointyhat to:	kevlo (myself)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pointyhat to:	kevlo (myself)
</pre>
</div>
</content>
</entry>
<entry>
<title>Prefer NULL over 0 for pointers</title>
<updated>2012-10-09T08:27:40+00:00</updated>
<author>
<name>Kevin Lo</name>
<email>kevlo@FreeBSD.org</email>
</author>
<published>2012-10-09T08:27:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a10cee30c94cf5944826d2a495e9cdf339dfbcc8'/>
<id>a10cee30c94cf5944826d2a495e9cdf339dfbcc8</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Second-to-last commit implementing Capsicum capabilities in the FreeBSD</title>
<updated>2011-08-11T12:30:23+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2011-08-11T12:30:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a9d2f8d84f69e98100b5746816b35666bcf992ac'/>
<id>a9d2f8d84f69e98100b5746816b35666bcf992ac</id>
<content type='text'>
kernel for FreeBSD 9.0:

Add a new capability mask argument to fget(9) and friends, allowing system
call code to declare what capabilities are required when an integer file
descriptor is converted into an in-kernel struct file *.  With options
CAPABILITIES compiled into the kernel, this enforces capability
protection; without, this change is effectively a no-op.

Some cases require special handling, such as mmap(2), which must preserve
information about the maximum rights at the time of mapping in the memory
map so that they can later be enforced in mprotect(2) -- this is done by
narrowing the rights in the existing max_protection field used for similar
purposes with file permissions.

In namei(9), we assert that the code is not reached from within capability
mode, as we're not yet ready to enforce namespace capabilities there.
This will follow in a later commit.

Update two capability names: CAP_EVENT and CAP_KEVENT become
CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they
represent.

Approved by:	re (bz)
Submitted by:	jonathan
Sponsored by:	Google Inc
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kernel for FreeBSD 9.0:

Add a new capability mask argument to fget(9) and friends, allowing system
call code to declare what capabilities are required when an integer file
descriptor is converted into an in-kernel struct file *.  With options
CAPABILITIES compiled into the kernel, this enforces capability
protection; without, this change is effectively a no-op.

Some cases require special handling, such as mmap(2), which must preserve
information about the maximum rights at the time of mapping in the memory
map so that they can later be enforced in mprotect(2) -- this is done by
narrowing the rights in the existing max_protection field used for similar
purposes with file permissions.

In namei(9), we assert that the code is not reached from within capability
mode, as we're not yet ready to enforce namespace capabilities there.
This will follow in a later commit.

Update two capability names: CAP_EVENT and CAP_KEVENT become
CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they
represent.

Approved by:	re (bz)
Submitted by:	jonathan
Sponsored by:	Google Inc
</pre>
</div>
</content>
</entry>
</feed>
