core Unix-like operating system of macOS, iOS, etc.
~13 min read
Darwin is the core Unix-like operating system of macOS, iOS, watchOS, tvOS, iPadOS, audioOS, visionOS, and bridgeOS. It previously existed as an independent open-source operating system, first released by Apple in 2000. It is composed of code derived from NeXTSTEP, FreeBSD and other BSD operating systems, Mach, and other free software projects' code, as well as code developed by Apple. Darwin's unofficial mascot is Hexley the Platypus.
Darwin is mostly POSIX-compatible, but has never, by itself, been certified as compatible with any version of POSIX. Starting with Leopard, macOS has been certified as compatible with the Single UNIX Specification version 3 (SUSv3).
via Wikipedia infobox
XNU kernel is part of the Darwin operating system for use in macOS and iOS operating systems. XNU is an acronym for X is Not Unix. XNU is a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit. XNU runs on x86 64 and ARM64 for both single processor and multi-processor configurations. config - configurations for exported apis for supported architecture and platform SETUP - Basic set of tools used for configuring the kernel, versioning and kextsymbol management. EXTERNAL HEADERS - Headers sourced from other projects to avoid dependency cycles when building. These headers should be regularly synced when source is updated. libkern - C++ IOKit library code for handling of drivers and kexts. libsa - kernel bootstrap code for startup libsyscall - syscall library interface for userspace programs libkdd - source for user library for parsing kernel data like kernel chunked data. makedefs - top level rules and defines for kernel build. osfmk - Mach kernel based subsystems pexpert - Platform specific code like interrupt handling, atomics etc. security - Mandatory Access Check policy interfaces and related implementation. bsd - BSD subsystems code tools - A set of utilities for testing, debugging and profiling kernel. The xnu make system can build kernel based on KERNEL CONFIGS & ARCH CONFIGS variables as arguments. Here is the syntax: Additionally, there is support for configuring architectures through ARCH CONFIGS and kernel configurations with KERNEL CONFIGS . Note: By default, the architecture is set to the build machine's architecture, and the default kernel config is set to build for DEVELOPMENT . This will also create a bootable image, kernel.[config], and a kernel binary with symbols, kernel.[config].unstripped. Remember to replace DEVELOPMENT and ARM64 with the appropriate build and platform. Extra Flags: You can pass additional flags to the C compiler at the command line with the EXTRA CFLAGS build setting. These flags are appended to the base CFLAGS , and the default value for the setting is an empty string. $ make MAKEJOBS=-j8 this will use 8 processes during the build. The default is 2x the number of active CPUS. $ make -j8 the standard command-line option is also accepted $ make -w trace recursive make invocations. Useful in combination with VERBOSE=YES $ make BUILD LTO=0 build without LLVM Link Time Optimization $ make BOUND CHECKS=0 disable -fbound-attributes for this build $ make REMOTEBUILD=user@remotehost perform build on remote host $ make BUILD CODE COVERAGE=1 build with support for collecting code coverage information The XNU build system can optionally output color-formatted build output. To enable this, you can either set the XNU LOGCOLORS environment variable to y , or you can pass LOGCOLORS=y to the make command. By default, a DWARF debug information repository is created during the install phase; this is a "bundle" named kernel.development. .dSYM To select the older STABS debug information format (where debug information is embedded in the kernel.development.unstripped image), set the BUILD STABS environment variable. To test the xnu kernel, you need to build a kernelcache that links the kexts and kernel together into a single bootable image. To build a kernelcache you can use the following mechanisms: Using automatic kernelcache generation with kextd . The kextd daemon keeps watching for changing in /System/Library/Extensions directory. So you can setup new kernel as The development kernel and iBoot supports configuring boot arguments so that we can safely boot into test kernel and, if things go wrong, safely fall back to previously used kernelcache. Following are the steps to get such a setup: 1. Create kernel cache using the kextcache command as /kernelcache.test 2. Copy exiting boot configurations to alternate file The --nextonly flag specifies that use the boot.plist configs only for one boot
Excerpt from the source-code README · 22,120 chars · not written by Vinony
via Wikidata · CC0
via Wikidata sitelinks · CC0
Discovered by embedding cosine similarity (sentence-transformers MiniLM, 384-dim).