[src/trunk]: src/sys/kern callout(9): Nix trailing whitespace.

[riastradh <riastradh%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/c2efe7927633
branches:  trunk
changeset: 372145:c2efe7927633
user:      riastradh <riastradh%NetBSD.org@localhost>
date:      Fri Oct 28 21:52:22 2022 +0000

description:
callout(9): Nix trailing whitespace.

No functional change intended.

diffstat:

 sys/kern/kern_timeout.c |  8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diffs (36 lines):

diff -r 8d3a9af95f34 -r c2efe7927633 sys/kern/kern_timeout.c
--- a/sys/kern/kern_timeout.c   Fri Oct 28 21:52:02 2022 +0000
+++ b/sys/kern/kern_timeout.c   Fri Oct 28 21:52:22 2022 +0000
@@ -1,4 +1,4 @@
-/*     $NetBSD: kern_timeout.c,v 1.70 2022/06/29 22:27:01 riastradh Exp $      */
+/*     $NetBSD: kern_timeout.c,v 1.71 2022/10/28 21:52:22 riastradh Exp $      */
 
 /*-
  * Copyright (c) 2003, 2006, 2007, 2008, 2009, 2019 The NetBSD Foundation, Inc.
@@ -59,7 +59,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: kern_timeout.c,v 1.70 2022/06/29 22:27:01 riastradh Exp $");
+__KERNEL_RCSID(0, "$NetBSD: kern_timeout.c,v 1.71 2022/10/28 21:52:22 riastradh Exp $");
 
 /*
  * Timeouts are kept in a hierarchical timing wheel.  The c_time is the
@@ -74,7 +74,7 @@
  * We use the fact that any element added to the queue must be added with
  * a positive time.  That means that any element `to' on the queue cannot
  * be scheduled to timeout further in time than INT_MAX, but c->c_time can
- * be positive or negative so comparing it with anything is dangerous. 
+ * be positive or negative so comparing it with anything is dangerous.
  * The only way we can use the c->c_time value in any predictable way is
  * when we calculate how far in the future `to' will timeout - "c->c_time
  * - c->c_cpu->cc_ticks".  The result will always be positive for future
@@ -547,7 +547,7 @@
                }
 
                /*
-                * Re-lock the callout and check the state of play again. 
+                * Re-lock the callout and check the state of play again.
                 * It's a common design pattern for callouts to re-schedule
                 * themselves so put a stop to it again if needed.
                 */