guides: Update bincompat

configs/contributing.sidebar.json

@@ -26,6 +26,10 @@
         {
           "title": "Coding Conventions",
           "path": "/docs/contributing/coding-conventions"
+        },
+        {
+          "title": "Adding to the App Catalog",
+          "path": "/docs/contributing/adding-to-the-app-catalog"
         }
       ]
     }

content/docs/concepts/compatibility.mdx

@@ -6,11 +6,40 @@
 ---
 
 <Info>
-This page contains extracts from [an article published to **USENIX
+Parts of this document contains extracts from [an article published to **USENIX
 ;login**](https://www.usenix.org/publications/loginonline/unikraft-and-coming-age-unikernels)
 about Unikraft.
 </Info>
 
+One challenge with Unikraft is the potential porting effort required for new applications.
+To address this, Unikraft includes a **binary-compatibility layer** which allows the running of Linux binaries (ELFs) on top of Unikraft.
+
+For such a layer to work, Unikraft has the explicit goal to comply, as much as possible, with Linux's ABI (_Application Binary Interface_), providing a large range of its system call interface.
+Concretely, in Unikraft this is handled through its [**system call shim layer**](/docs/internals/syscall-shim) (also called **syscall shim**), which provides Linux-style mappings of system call numbers to actual system call handler functions.
+
+<Info>
+Currently, binary-compatibility is available on x86_64, with work ongoing to make this available for AArch64.
+Also note that KVM is currently the only supported hypervisor, with QEMU and Firecracker as VMMs (_Virtual Machine Monitors_).
+</Info>
+
+<Warning>
+Currently, binaries have to be built as PIE (*Position-Independent Executables*).
+This is the default build mode for the majority of Linux distributions, so it shouldn't cause any problems.
+</Warning>
+
+<Info>
+Note that, because Linux binaries are included, constructing new Linux binaries requires a Linux or Linux-compatible development environement (such as WSL - _Windows Subsystem for Linux_).
+This is only the case for building binaries -- prebuilt binaries can be used and the ELF loader app itself can be built on multiple platforms (Linux, Windows, macOS).
+</Info>
+
+Binary-compatible apps are located in the Unikraft [application `catalog` repository](https://github.com/unikraft/catalog).
+Follow the guides below to know how to use and develop for the application catalog:
+
+- [Using the Application Catalog](/guides/using-the-app-catalog)
+- [Behind the Scenes with the Application Catalog](/guides/catalog-behind-the-scenes)
+- [Using Firecracker in the Application Catalog](/guides/catalog-using-firecracker)
+- [Adding Applications to the Catalog](/docs/contributing/adding-to-the-app-catalog)
+
 While Linux has over 350 system calls, previous
 [studies](https://dl.acm.org/doi/10.1145/2901318.2901341) have shown through
 static analysis that only a subset (224) are needed to run a Ubuntu
@@ -101,10 +130,10 @@
   ratio={5/2}
   src="/diagrams/unikraft-posix-sysusage.svg"
   title="Figure 2"
   description="Number of syscalls statically identified and dynamically traced for applications under traditional (bench) and unit tests (suite) workloads. Traced syscalls are broken down into the ones that can be stubbed and/or faked and the required ones."
 />
 
 
 The key insight is that applications are resilient to a significant portion of
 syscalls being stubbed and faked, and that the number of implemented syscalls
 they require to correctly run is significantly lower than the output of the
@@ -150,7 +179,7 @@
 42% for test suites, and 60% for traditional workloads. This shows that the
 effort to provide comprehensive (test suite level) support for these popular
 applications is relatively limited, and is even lower when considering partial
 support i.e. traditional workloads. We observe that the system calls that can be
 stubbed/faked vary among applications. As an indication, the number of system
 calls that would need to be effectively implemented for all these 5 applications
 to be supported is 78 for test suites and only 37 for traditional benchmarks
@@ -158,7 +187,7 @@
 A second observation is that static analysis produces many false positives and
 as such yields a large overestimation of the system calls made by an
 application. For example on Redis, binary-level static analysis identifies 89
 system calls, vs. 68 dynamically traced from the test suite. These trends are
 the same for all programs. This is due to multiple reasons such as dead code but
 also the imprecision of binary-level static analysis. A concrete example is when
 such analysis encounters a system call wrapper like `setxid`: it may mark all