cleanup(docs): edit libs page content for technical clarity

Signed-off-by: Melissa Kilby <[email protected]>

docs/index.md

@@ -1,10 +1,13 @@
 # Falcosecurity drivers
 
-## Falco drivers kernel testing matrixes
+## Falco Drivers Kernel Testing
 
-Here you can find kernel testing support matrixes for [Falco](https://falco.org/) drivers.  
-For more info, make sure to read the [driver kernel testing framework proposal](https://github.com/falcosecurity/libs/blob/master/proposals/20230530-driver-kernel-testing-framework.md).  
+This page gives you the latest updates on Falco's kernel driver testing. We test each driver (kmod, bpf, modern_bpf) on various kernels and distributions (which we call the kernel testing matrix). These tests ensure that each driver not only compiles correctly, but also functions and provides the right events to userspace. These tests are super important to make sure Falco keeps working well and adopters can update or change their kernels without any problems. Another positive result for the project maintainers is the increased confidence in releasing new versions of Falco.
 
-## Syscalls Report
+To learn more, check out the [kernel testing framework proposal](https://github.com/falcosecurity/libs/blob/master/proposals/20230530-driver-kernel-testing-framework.md) and visit the official Falco [website](https://falco.org/).
 
-You can also find the list of supported syscalls by our drivers, be it through specific filler or generic.
+## Supported Syscalls Report
+
+The Falco Projects' kernel drivers support monitoring a range of syscalls. For a subset of syscalls (indicated with 🟡), we only monitor when the syscalls are triggered (internally in libs, we refer to these as generic syscalls), but we do not extract the syscall arguments for those.
+
+On the other hand, syscalls indicated with 🟢 in the report are fully monitored. This means we read and parse each syscall argument. You can learn more about the specific syscall arguments for these syscalls by referring to the libs' [event_table](https://github.com/falcosecurity/libs/blob/master/driver/event_table.c) or the official Linux man pages.

docs/matrix.md

@@ -1,15 +1,19 @@
-# Home of Falco drivers kernel testing matrixes
+# Home of Falco Drivers Kernel Testing
 
-Basically, we use Ansible playbooks to spawn Firecracker microvms where we can test:  
+We use Ansible playbooks to spawn Firecracker microVMs where we can test:  
 
-* kmod and ebpf drivers build
-* scap-open run with {kmod,ebpf,modern-bpf}
+* kmod and bpf driver builds.
+* `scap-open` runs with {kmod,bpf,modern_bpf}.
 
-The modern-bpf driver-enabled scap-open is built using the exactly same process used by [Falco release pipeline](https://github.com/falcosecurity/falco/blob/master/.github/workflows/reusable_build_packages.yaml#L15):   
+Going into more detail, we list kmod and bpf builds separately because these drivers need to be compiled specifically for each kernel release. In the actual microVM, we perform these builds using the corresponding system compiler (gcc for kmod and clang for bpf). That way, we ensure the use of the most appropriate compiler version.
 
-* the modern bpf skeleton is built on a Fedora machine
-* scap-open with embedded modern-bpf skeleton is built on a centos7 machine to allow largest possible support (old glibc version)
-* scap-open binary is copied to each spawned vm
+In contrast, modern BPF isn't tied to a particular kernel release. This is because of the CO-RE (Compile Once - Run Everywhere) feature of the modern BPF driver. As a result, we only compile the modern BPF skeleton once and then include it into `scap` during the linking process -- exactly how it's done in the official [Falco release pipeline](https://github.com/falcosecurity/falco/blob/master/.github/workflows/reusable_build_packages.yaml#L15). You can find even more details about modern BPF in the libs [README](https://github.com/falcosecurity/libs/tree/master#build).
+
+Here's some information about the steps in this regard:
+
+* modern BPF skeleton is built on a Fedora machine.
+* `scap-open` with embedded modern BPF skeleton is built on a centos7 machine to allow broad support (old GLIBC versions).
+* `scap-open` binary is copied to each spawned VM.
 
 ## Supported Archs
 
@@ -20,6 +24,6 @@ For now, supported architectures are:
 
 ## Glossary
 
-* 🟢 -> means that the test was successful
-* 🟡 -> means that the test was skipped; you can click the symbol to reach the test section and checkout why the test was skipped.
-* ❌ -> means that the test failed; you can click the symbol to reach the test section and checkout why the test failed.
+* 🟢 -> test was successful.
+* 🟡 -> test was skipped; you can click the symbol to reach the test section and checkout why the test was skipped.
+* ❌ -> test failed; you can click the symbol to reach the test section and checkout why the test failed.

docs/syscalls.md

@@ -1,10 +1,14 @@
-# Home of Falco drivers syscalls report
+# Home of Falco Drivers Syscalls Report
 
-Thanks to our [syscalls-bumper](https://github.com/falcosecurity/syscalls-bumper) project, we are able to always support latest syscalls added to linux kernel.  
-Support for new syscalls is initially automatically added by the tool as generic events; when needed, a generic event can be made "specific",  
-by creating a whole new event to track it.
+Thanks to our [syscalls-bumper](https://github.com/falcosecurity/syscalls-bumper) project, we are able to always support latest syscalls added to the Linux kernel.
+
+Our automation adds new syscalls as generic events (you can find the definition below to better understand what this term means within our libs). If necessary, developers can create new parsers to extract and make available each syscall argument. Internally, we refer to the extractors on the kernel side as "fillers". This process also involves the creation of a new event type in libsinsp.
 
 ## Glossary
 
-* 🟢 -> means that the syscall is implemented as a specific event
-* 🟡 -> means that the syscall is implemented as a generic event
+The Falco Projects' kernel drivers support monitoring a range of syscalls. For a subset of syscalls (indicated with 🟡), we only monitor when the syscalls are triggered (internally in libs, we refer to these as generic syscalls), but we do not extract the syscall arguments for those.
+
+On the other hand, syscalls indicated with 🟢 in the report are fully monitored. This means we read and parse each syscall argument. You can learn more about the specific syscall arguments for these syscalls by referring to the libs' [event_table](https://github.com/falcosecurity/libs/blob/master/driver/event_table.c) or the official Linux man pages.
+
+* 🟢 -> syscall is implemented as dedicated libsinsp event type and each argument of the syscall is extracted and parsed.
+* 🟡 -> syscall is implemented as a generic event; we only monitor when a syscall triggers.