Commit-ID:  0e2815de552a638295cfdaf0865e575573bf263e
Gitweb:     http://git.kernel.org/tip/0e2815de552a638295cfdaf0865e575573bf263e
Author:     Peter Zijlstra <pet...@infradead.org>
AuthorDate: Wed, 9 Sep 2015 09:12:44 +0200
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Mon, 14 Sep 2015 11:09:33 +0200

x86/headers: Clean up too long lines

Signed-off-by: Peter Zijlstra <pet...@infradead.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: b...@alien8.de
Cc: brge...@gmail.com
Cc: dvlas...@redhat.com
Cc: l...@amacapital.net
Cc: mikko.rap...@iki.fi
Cc: o...@redhat.com
Link: 
http://lkml.kernel.org/r/20150909071244.gm3...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/uapi/asm/sigcontext.h | 57 ++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/arch/x86/include/uapi/asm/sigcontext.h 
b/arch/x86/include/uapi/asm/sigcontext.h
index 4411e6a..d485232 100644
--- a/arch/x86/include/uapi/asm/sigcontext.h
+++ b/arch/x86/include/uapi/asm/sigcontext.h
@@ -2,16 +2,16 @@
 #define _UAPI_ASM_X86_SIGCONTEXT_H
 
 /*
- * Linux signal context definitions. The sigcontext includes a complex 
hierarchy of CPU
- * and FPU state, available to user-space (on the stack) when a signal handler 
is
- * executed.
+ * Linux signal context definitions. The sigcontext includes a complex
+ * hierarchy of CPU and FPU state, available to user-space (on the stack) when
+ * a signal handler is executed.
  *
- * As over the years this ABI grew from its very simple roots towards 
supporting more and
- * more CPU state organically, some of the details (which were rather clever 
hacks back
- * in the days) became a bit quirky by today.
+ * As over the years this ABI grew from its very simple roots towards
+ * supporting more and more CPU state organically, some of the details (which
+ * were rather clever hacks back in the days) became a bit quirky by today.
  *
- * The current ABI includes flexible provisions for future extensions, so we 
won't have
- * to grow new quirks for quite some time. Promise!
+ * The current ABI includes flexible provisions for future extensions, so we
+ * won't have to grow new quirks for quite some time. Promise!
  */
 
 #include <linux/compiler.h>
@@ -23,27 +23,32 @@
 
 /*
  * Bytes 464..511 in the current 512-byte layout of the FXSAVE/FXRSTOR frame
- * are reserved for SW usage. On CPUs supporting XSAVE/XRSTOR, these bytes
- * are used to extend the fpstate pointer in the sigcontext, which now
- * includes the extended state information along with fpstate information.
+ * are reserved for SW usage. On CPUs supporting XSAVE/XRSTOR, these bytes are
+ * used to extend the fpstate pointer in the sigcontext, which now includes the
+ * extended state information along with fpstate information.
  *
- * If sw_reserved.magic1 == FP_XSTATE_MAGIC1 then there's a 
sw_reserved.extended_size
- * bytes large extended context area present. (The last 32-bit word of this 
extended
- * area (at the fpstate+extended_size-FP_XSTATE_MAGIC2_SIZE address) is set to
+ * If sw_reserved.magic1 == FP_XSTATE_MAGIC1 then there's a
+ * sw_reserved.extended_size bytes large extended context area present. (The
+ * last 32-bit word of this extended area (at the
+ * fpstate+extended_size-FP_XSTATE_MAGIC2_SIZE address) is set to
  * FP_XSTATE_MAGIC2 so that you can sanity check your size calculations.)
  *
- * This extended area typically grows with newer CPUs that have larger and 
larger
- * XSAVE areas.
+ * This extended area typically grows with newer CPUs that have larger and
+ * larger XSAVE areas.
  */
 struct _fpx_sw_bytes {
-       /* If set to FP_XSTATE_MAGIC1 then this is an xstate context. 0 if a 
legacy frame. */
+       /*
+        * If set to FP_XSTATE_MAGIC1 then this is an xstate context.
+        * 0 if a legacy frame.
+        */
        __u32                           magic1;
 
        /*
         * Total size of the fpstate area:
         *
         *  - if magic1 == 0 then it's sizeof(struct _fpstate)
-        *  - if magic1 == FP_XSTATE_MAGIC1 then it's sizeof(struct _xstate) 
plus extensions (if any)
+        *  - if magic1 == FP_XSTATE_MAGIC1 then it's sizeof(struct _xstate)
+        *    plus extensions (if any)
         */
        __u32                           extended_size;
 
@@ -66,13 +71,13 @@ struct _fpx_sw_bytes {
 /*
  * As documented in the iBCS2 standard:
  *
- * The first part of "struct _fpstate" is just the normal i387
- * hardware setup, the extra "status" word is used to save the
- * coprocessor status word before entering the handler.
+ * The first part of "struct _fpstate" is just the normal i387 hardware setup,
+ * the extra "status" word is used to save the coprocessor status word before
+ * entering the handler.
  *
- * The FPU state data structure has had to grow to accommodate the
- * extended FPU state required by the Streaming SIMD Extensions.
- * There is no documented standard to accomplish this at the moment.
+ * The FPU state data structure has had to grow to accommodate the extended FPU
+ * state required by the Streaming SIMD Extensions.  There is no documented
+ * standard to accomplish this at the moment.
  */
 
 /* 10-byte legacy floating point register: */
@@ -137,8 +142,8 @@ struct _fpstate_32 {
  *        'struct _fpstate' so that you can always assume the _fpstate portion
  *        exists so that you can check the magic value.
  *
- * Note2: Reserved fields may someday contain valuable data. Always 
save/restore
- *        them when you change signal frames.
+ * Note2: Reserved fields may someday contain valuable data. Always
+ *       save/restore them when you change signal frames.
  */
 struct _fpstate_64 {
        __u16                           cwd;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to