Fixing some typos in the documentation

content/docs/cli/filesystem.mdx

@@ -9,7 +9,7 @@
 A filesystem serves as the underlying structure that allows an operating system to store, retrieve, and organize files on storage mediums.
 Whether it's a traditional server or virtual machine, or a more specialized environment like a unikernel, the role of a filesystem remains the same: to enable the reading and writing of data.
 
 
 ## The Role of Filesystems in Unikernels
 
 At its core, the primary purpose of a filesystem in a unikernel is to provide a structured and efficient means of organizing and accessing data.
@@ -26,7 +26,7 @@
 In this documentation, you will be guided in different approaches to building support for a filesystems, the different ways in which filesystems are used throughout the lifecycle of a unikernel (both at compile-time and at runtime), the ways for realising those filesystems, using them and populating (or seeding) filesystems to the unikernel application.
 Ultimately, this will enable you to design and use one or many filesystems for your unikernel application appropriately.
 
 
 ## Root Filesystems
 
 The first consideration to make when approaching the customisation of the filesystem in general is to start with the root filesystem.
@@ -36,12 +36,12 @@
 
 Thanks to Unikraft's highly modular structure, building a unikernel with root filesystem support is both trivial and left up to the application developer and ultimately the application use case.
 Some unikernels may not require a filesystem at all if the application does not read or write any files.
-In this case, neither the underlying filesystem subsystem (`vfscore`) or a root filesystem can are compiled into the unikernel binary.
+In this case, neither the underlying filesystem subsystem (`vfscore`) nor a root filesystem have to be compiled into the unikernel binary.
 For example, this may be use in lambda-type use cases.
 However, many applications do need access to files, configuration data, a temporary file directory scratch pad (e.g. `/tmp`) or other have file-based resource needs.
 In such cases, a root filesystem is essential.
 
 
 ### Classes of Root Filesystems
 
 Unikraft supports essentially two classes of root filesystems: initial ramdisks ("initrd" or "initram" for short) and external volumes.
@@ -66,7 +66,7 @@
   unikernel binary application with a root filesystem."
 />
 
 
 #### Initial Ramdisk Filesystem (initramfs)
 
 Traditionally, initramfs is a temporary root filesystem used during the initial stages of the boot sequence of an operating system to to set up the environment before transitioning to the real root filesystem.
@@ -75,7 +75,7 @@
 This is a common approach with unikernels, and can be compared to the resulting filesystem which is generated after building a `Dockerfile` (see later [how to use a `Dockerfile` to generate a rootfs](#building-and-packaging-a-static-initram-root-filesystem)).
 
 Traditionally, the initram filesystem is provided as an external archive file and virtual machine monitors have specific options to allow setting the path to this archive file.
 For example, with QEMU this is handled via the `-initrd` flag.  This root filesystem configuration can be seen in [Figure 1 (a)](#classes-of-root-filesystems).
 
 <Warning title="Memory Requirements">
 When instantiating a unikernel image with an external initramfs and when specifying an amount of memory, you must supply at least the size of the initramfs as minimum amount of memory because this file will be loaded directly into memory during boot time.
@@ -85,7 +85,7 @@
 
 Initram is a simple and effective way of populating an initial tree of data as the root filesystem (also known as "seeding the root filesystem") to the unikernel during boot time and giving the application access to essential files for use during its runtime.
 Throughout the lifecycle of the application, this root filesystem is held in memory (via [Unikraft's internal library `ramfs`](https://github.com/unikraft/unikraft/tree/staging/lib/ramfs)) and therefore it is not persistent.
 A good example of use cases for such filesystems are static configuration files; e.g `/etc/resolv.conf` for dynamic name resolution (used in most standard libc's) or static configuration files used by your application (such as [Nginx's config files](https://github.com/unikraft/catalog/blob/main/library/nginx/1.15/rootfs/nginx/conf/nginx.conf)).
 These files do not change often (or at all) once they are initially written and therefore make for good candidates to be placed within initramfs (or as embedded initramfs as you'll discover in the next section).
 
 Towards optimizing against a performance-oriented KPI, initramfs is a good choice since its underlying hardware implementation is backed by RAM.
@@ -116,7 +116,7 @@
     # configure mounting options at boot time via
     # kernel command-line arguments:
     CONFIG_LIBVFSCORE_FSTAB: 'y'
 ```
 </Info>
 
 <Info colorScheme="purple" title="Supported Initramfs Formats">
@@ -125,12 +125,12 @@
 
 | Format | KConfig Option   | Description |
 |--------|------------------|-------------|
 | `cpio` | `CONFIG_LIBCPIO` | CPIO (Copy-In, Copy-Out) archives are uncompressed or minimally compressed to keep them simple and efficient.  This format is seamlessly integrated into KraftKit, meaning unless you specifically wish to use an alternative format, you need not worry about alternatives. |
 
 More formats, such as tarballs, are planned: [follow the GitHub Project board](https://github.com/orgs/unikraft/projects/24/views/13).
 </Info>
 
 
 #### Embedded Initial Ramdisk Filesystems (einitrds)
 
 Unikraft supports embedding the initram archive file within the kernel binary directly as shown in [Figure 1 (b)](#classes-of-root-filesystems).
@@ -174,7 +174,7 @@
     # If you've set `rootfs` to a directory or a Dockerfile,
     # this will be the default location of its output.
     CONFIG_LIBVFSCORE_ROOTFS_EINITRD_PATH: .unikraft/build/initramfs.cpio
 ```
 </Info>
 
 

content/docs/cli/packaging.mdx

@@ -64,7 +64,7 @@ Components are one of 5 unique types:
 | `app`  | The final component type is that of a fully functioning unikernel.  The `app` component defines the use of the `core`, a `arch` and `plat` combination, as well as a list of `lib`s. |
 
 
-## Package Manages
+## Package Managers
 
 Internal to `kraft` are programmable package managers that allows you to fetch
 resources that either comprise of library components (distributed through [the

content/docs/concepts/virtualization.mdx

@@ -22,7 +22,7 @@ properly.
 
 A hypervisor incorporates hardware-enabled multiplexing and segmentation of
 compute resources in order to better utilize, better secure and better
-facilitate the instantenous runtime of user-defined programs. Through By the
+facilitate the instantenous runtime of user-defined programs. By the
 means of a virtual machine, an operating system is unaware of the multiplexing
 which happens to facilitate its existence. The hypervisor emulates devices on
 behalf of the guest OS, including providing access to virtual CPUs, virtual

content/docs/internals/architecture.mdx

@@ -103,33 +103,3 @@ micro-library (3️), or optimize throughput by oding against the ukblock API
 (8️).  Schedulers are also pluggable (4️), and each CPU core can run a
 different scheduler.
 
-
-
-
-
-
-
-###
-
-
-The Unikraft Core
-The Unikraft core is the actual kernel code, and is comprised of several components:
-
-the architecture code: This defines behaviours and hardware interactions
-specific to the target architecture (x86_64, ARM, RISC-V). For example, for the
-x86_64 architecture, this component defines the usable registers, data types
-sizes and how Thread-Local Storage should happen.
-
-the platform code: This defines interaction with the underlying hardware,
-depending on whether a hypervisor is present or not, and which hypervisor is
-present. For example, if the KVM hypervisor is present, Unikraft will behave
-almost as if it runs bare-metal, needing to initialize the hardware components
-according to the manufacturer specifications. The difference from bare-metal is
-made only at the entry, where some information, like the memory layout, the
-available console, are supplied by the bootloader (Multiboot) and there’s no
-need to interact with the BIOS or UEFI. In the case of Xen, many of the
-hardware-related operations must be done through hypercalls, thus reducing the
-direct interaction of Unikraft with the hardware.
-
-internal libraries: These define behaviour independent of the hardware, like scheduling, networking, memory allocation, basic file systems. These libraries are the same for every platform or architecture, and rely on the platform code and the architecture code to perform the needed actions. The internal libraries differ from the external ones in the implemented functionalities. The internal ones define parts of the kernel, while the external ones define user-space level functionalities. For example, uknetdev and lwip are 2 libraries that define networking components. Uknetdev is an internal library that interacts with the network card and defines how packages are sent using it. Lwip is an external library that defines networking protocols, like IP, TCP, UDP. This library knows that the packages are somehow sent over the NIC, but it is not concerned how. That is the job of the kernel.
-The core, toghether with the external libraries, applications and platform codes, form the final Unikernel.

content/docs/internals/build-system.mdx

@@ -231,7 +231,7 @@ APPNAME_FILENAME_VARIANT_INCLUDES-y         file and variant of the library
 Unikraft's configuration system is based on [Linux's KConfig system](https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html).
 With `Config.uk` you define possible configurations for your application and define dependencies to other libraries.
 This file is included by Unikraft to render the menu-based configuration, and to load and store configurations (aka `.config`).
-Each setting that is defined in this file will be globally populated as a set variable for all `Makefile.uk` files, as well as a defined macro in your source code when you use `"#include <uk/config.h>"`.
+Each setting that is defined in this file will be globally populated as a set variable for all `Makefile.uk` files, as well as a defined macro in your source code when you use `#include <uk/config.h>`.
 Please ensure that all settings are properly namespaced.
 They should begin with `[APPNAME]_` (e.g. `APPHELLOWORLD_`).
 Please also note that some variable names are predefined for each application or library namespace (see [`Makefile.uk`](/docs/internals/build-system/#makefileuk)).