Merge branch 'main' into stablestable

1 files changed, 0 insertions, 209 deletions

diff --git a/share/misc/style b/share/misc/style
deleted file mode 100644
index 0a994e8..0000000
--- a/share/misc/style
+++ /dev/null
@@ -1,209 +0,0 @@
-/*
- * Copyright (c) 2023 Ian Marco Moffett and the Osmora Team.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * 1. Redistributions of source code must retain the above copyright notice,
- *    this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. Neither the name of Hyra nor the names of its
- *    contributors may be used to endorse or promote products derived from
- *    this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include <sys/cdefs.h>
-
-/*
- * Vim config in share/misc/vimrc
- */
-
-/*
- * Metadata goes in *.c files
- */
-__KERNEL_META("$Hyra$: style.c, Ian Marco Moffett, "
-              "Hyra style guide");
-/*
- * VERY important single-line comments look like this.
- */
-
-/* Most single-line comments look like this. */
-
-/*
- * Multi-line comments look like this.  Make them real sentences.  Fill
- * them so they look like real paragraphs.
- */
-
-/*
- * Attempt to wrap lines longer than 80 characters appropriately.
- * Refer to the examples below for more information.
- */
-
-/*
- * EXAMPLE HEADER FILE.
- * A header file should protect itself against
- * multiple inclusion.
- */
-
-/*
- * If your header as a manpage tied to it use
- * write a comment similar to the below comment
- */
-
-/*
- * For documentation: See foo(9)
- */
-
- #ifndef _SYS_FOO_H_
- #define _SYS_FOO_H_
-
-
-/*
- * extern declarations must only appear in header files, not in .c
- * files, so the same declaration is used by the .c file defining it
- * and the .c file using it, giving the compiler the opportunity to
- * detect type errors.
- *
- * extern function declarations should not use the extern keyword,
- * which is unnecessary.
- *
- * Exception: A subroutine written in assembly in an adjacent .S file,
- * which is used only in one .c file, may be declared in the .c file.
- */
-extern int g_foo;
-
-int funnify(const char *s);
-
-#endif     /* !_SYS_FOO_H_ */
-
-/*
- * END OF EXAMPLE HEADER FILE
- */
-
-/*
- * If a header file requires structures, defines, typedefs, etc. from
- * another header file it should include that header file and not depend
- * on the including file for that header including both.  If there are
- * exceptions to this for specific headers it should be clearly documented
- * in the headers and, if appropriate, the documentation.  Nothing in this
- * rule should suggest relaxation of the multiple inclusion rule and the
- * application programmer should be free to include both regardless.
- */
-
-/*
- * Kernel include files come first.
- */
-#include <sys/param.h>      /* <sys/param.h> first, */
-#include <sys/types.h>      /*   <sys/types.h> next, */
-#include <sys/ioctl.h>      /*   and then the rest, */
-#include <sys/socket.h>     /*   sorted lexicographically.  */
-#include <sys/stat.h>
-#include <sys/wait.h>
-
-
-/*
- * Macros are capitalized, parenthesized, and should avoid side-effects.
- * If they are an inline expansion of a function, the function is defined
- * all in lowercase, the macro has the same name all in uppercase.
- * If the macro is an expression, wrap the expression in parentheses.
- * If the macro is more than a single statement, use ``do { ... } while (0)''
- * or ``do { ... } while (false)'', so that a trailing semicolon works.
- * Right-justify the backslashes; it makes it easier to read.
- */
-#define MACRO(v, w, x, y)               \
-    do {                                \
-        v = (x) + (y);                  \
-        w = (y) + 2;                    \
-    } while (0)
-
-};
-
-/*
- * Sometimes we want a macro to be conditionally defined for debugging
- * and expand to nothing (but still as statement) when we are not debugging:
- */
-#if defined(FOO_DEBUG)
-#define DPRINTF(...) KDEBUG(__VA_ARGS__)
-#else
-#define DPRINTF(...) __nothing
-#endif  /* defined(FOO_DEBUG) */
-
-/*
- * The function type must be declared on a line by itself
- * preceding the function.
- */
-static char *
-function(int fooy)
-{
-	/*
-	 * When declaring variables in functions, multiple variables per line
-	 * are okay. If a line overflows reuse the type keyword.
-	 *
-	 * Function prototypes and external data declarations should go in a
-	 * suitable include file.
-	 *
-	 * Avoid initializing variables in the declarations; move
-	 * declarations next to their first use, and initialize
-	 * opportunistically. This avoids over-initialization and
-	 * accidental bugs caused by declaration reordering.
-	 */
-     int foo, bar;
-
-     foo = 0;
-     bar = 0;
-	/*
-	 * Casts and sizeof's are not followed by a space.
-	 *
-	 * We parenthesize sizeof expressions to clarify their precedence:
-	 *
-	 * 	sizeof(e) + 4
-	 * not:
-	 *	sizeof e + 4
-	 *
-	 * We don't put a space before the parenthesis so that it looks like
-	 * a function call. We always parenthesize the sizeof expression for
-	 * consistency.
-	 *
-	 * On the other hand, we don't parenthesize the return statement
-	 * because there is never a precedence ambiguity situation (it is
-	 * a single statement).
-	 *
-	 * NULL is any pointer type, and doesn't need to be cast, so use
-	 * NULL instead of (struct foo *)0 or (struct foo *)NULL.  Also,
-	 * test pointers against NULL because it indicates the type of the
-	 * expression to the user. I.e. use:
-	 *
-	 *	(p = f()) == NULL
-	 * not:
-	 *	!(p = f())
-	 *
-	 * Don't use `!' for tests unless it's a boolean.
-	 * E.g. use "if (*p == '\0')", not "if (!*p)".
-	 *
-	 * Routines returning ``void *'' should not have their return
-	 * values cast to more specific pointer types.
-	 *
-	 * Prefer sizeof(*var) over sizeof(type) because if type changes,
-	 * the change needs to be done in one place.
-	 *
-	 * Prefer EXIT_FAILURE instead of random error codes.
-	 */
-
-	/* No parentheses are needed around the return value. */
-	return 0;
-}