svn commit: r242901 - head/sys/sys
Attilio Rao
attilio at FreeBSD.org
Sun Nov 11 23:25:48 UTC 2012
Author: attilio
Date: Sun Nov 11 23:25:47 2012
New Revision: 242901
URL: http://svnweb.freebsd.org/changeset/base/242901
Log:
Tweak comments.
In collabouration with: alc
Modified:
head/sys/sys/_mutex.h
head/sys/sys/_rwlock.h
Modified: head/sys/sys/_mutex.h
==============================================================================
--- head/sys/sys/_mutex.h Sun Nov 11 22:43:36 2012 (r242900)
+++ head/sys/sys/_mutex.h Sun Nov 11 23:25:47 2012 (r242901)
@@ -36,12 +36,11 @@
/*
* Sleep/spin mutex.
*
- * The layout of the first 2 members of struct mtx* is considered fixed.
- * More specifically, it is assumed that there is a member called mtx_lock
- * for every struct mtx* and that other locking primitive structures are
- * not allowed to use such name for their members.
- * If this needs to change, the bits in the mutex implementation might be
- * modified appropriately.
+ * All mutex implementations must always have a member called mtx_lock.
+ * Other locking primitive structures are not allowed to use this name
+ * for their members.
+ * If this rule needs to change, the bits in the mutex implementation must
+ * be modified appropriately.
*/
struct mtx {
struct lock_object lock_object; /* Common lock properties. */
@@ -50,11 +49,12 @@ struct mtx {
/*
* Members of struct mtx_padalign must mirror members of struct mtx.
- * mtx_padalign mutexes can use mtx(9) KPI transparently, without modifies.
- * When using pad-aligned mutexes within structures, they should generally
- * stay as the first member of the struct. This is because otherwise the
- * compiler can generate ever more padding for the struct to keep a correct
- * alignment for the mutex.
+ * mtx_padalign mutexes can use the mtx(9) API transparently without
+ * modification.
+ * Pad-aligned mutexes used within structures should generally be the
+ * first member of the struct. Otherwise, the compiler can generate
+ * additional padding for the struct to keep a correct alignment for
+ * the mutex.
*/
struct mtx_padalign {
struct lock_object lock_object; /* Common lock properties. */
Modified: head/sys/sys/_rwlock.h
==============================================================================
--- head/sys/sys/_rwlock.h Sun Nov 11 22:43:36 2012 (r242900)
+++ head/sys/sys/_rwlock.h Sun Nov 11 23:25:47 2012 (r242901)
@@ -37,12 +37,11 @@
/*
* Reader/writer lock.
*
- * The layout of the first 2 members of struct rwlock* is considered fixed.
- * More specifically, it is assumed that there is a member called rw_lock
- * for every struct rwlock* and that other locking primitive structures are
- * not allowed to use such name for their members.
- * If this needs to change, the bits in the rwlock implementation might be
- * modified appropriately.
+ * All reader/writer lock implementations must always have a member
+ * called rw_lock. Other locking primitive structures are not allowed to
+ * use this name for their members.
+ * If this rule needs to change, the bits in the reader/writer lock
+ * implementation must be modified appropriately.
*/
struct rwlock {
struct lock_object lock_object;
@@ -51,12 +50,12 @@ struct rwlock {
/*
* Members of struct rwlock_padalign must mirror members of struct rwlock.
- * rwlock_padalign rwlocks can use rwlock(9) KPI transparently, without
- * modifies.
- * When using pad-aligned rwlocks within structures, they should generally
- * stay as the first member of the struct. This is because otherwise the
- * compiler can generate ever more padding for the struct to keep a correct
- * alignment for the rwlock.
+ * rwlock_padalign rwlocks can use the rwlock(9) API transparently without
+ * modification.
+ * Pad-aligned rwlocks used within structures should generally be the
+ * first member of the struct. Otherwise, the compiler can generate
+ * additional padding for the struct to keep a correct alignment for
+ * the rwlock.
*/
struct rwlock_padalign {
struct lock_object lock_object;
More information about the svn-src-all
mailing list