[libc] document supported os ranges

[SchrodingerZhu]

LLVM-libc does not guarantee backward compatibility with operating systems that have reached their EOL.
Compatibility patches for obsolete operating systems will not be accepted.

For Linux, we support kernel versions as listed on kernel.org, including
longterm (not passed EOL date), stable, and mainline versions. We actively adapt new features
from linux-next.

For Windows, we plan to support products within their lifecycle. Please refer to
Search Product and Services Lifecycle Information for more information.

[llvmbot]

@llvm/pr-subscribers-libc

Author: Schrodinger ZHU Yifan (SchrodingerZhu)

Changes

LLVM-libc does not guarantee backward compatibility with operating systems that reaches their EOL.
Compatibility patch for obsolete operating systems will not be accepted.

For Linux, we support kernel versions as listed on kernel.org, including
longterm, stable, and mainline versions. We actively adapt new features
from linux-next.

For Windows, we support products within their lifecycle. Please refer to
Search Product and Services Lifecycle Information for more information.

---

Full diff: https://github.com/llvm/llvm-project/pull/118863.diff

1 Files Affected:

• (modified) libc/docs/index.rst (+10)

diff --git a/libc/docs/index.rst b/libc/docs/index.rst
index 6f759aa215b62c..c4cb12be1377e8 100644
--- a/libc/docs/index.rst
+++ b/libc/docs/index.rst
@@ -40,6 +40,16 @@ and MacOS have limited support (may be broken).  The Fuchsia platform is
 slowly replacing functions from its bundled libc with functions from this
 project.
 
+LLVM-libc does not guarantee backward compatibility with operating systems that reaches their EOL.
+Compatibility patch for obsolete operating systems will not be accepted.
+
+For Linux, we support kernel versions as listed on `kernel.org <https://kernel.org/>`_, including
+``longterm``, ``stable``, and ``mainline`` versions. We actively adapt new features
+from ``linux-next``.
+
+For Windows, we support products within their lifecycle. Please refer to 
+`Search Product and Services Lifecycle Information <https://learn.microsoft.com/en-us/lifecycle/products/?products=windows>`_ for more information.
+
 ABI Compatibility
 =================
 

[nickdesaulniers]

For implications to the codebase, this means that for our syscall wrappers, we have checks that SYS_<foo> is defined. If foo has been supported by all supported architectures for all versions of LTS linux, then we should not clutter the code with prepropecessor guards.

https://www.chromium.org/chromium-os/developer-library/reference/linux-constants/syscalls/ talks a little about this, but doesn't have the kernel version info. I swear on hacker news recently someone linked to a library from chromeos that was trying to do syscall wrappers. It looked interesting, but I cannot find it.

Also, we should stop looking at the host's kernel headers when building llvm-libc for linux, and always require they be passed in. Otherwise, we'll have the wrong syscall numbers when cross compiling.

[nickdesaulniers]

but doesn't have the kernel version info.

https://syscalls.mebeim.net/?table=x86/64/x64/latest looks handy.

[michaelrj-google]

I don't think we want to claim windows support until it's in a more stable place. Maybe rephrase to "For Windows we plan to support products within their lifecycle, but support is limited currently."

[SchrodingerZhu]

applied!

[petrhosek]

https://www.chromium.org/chromium-os/developer-library/reference/linux-constants/syscalls/ talks a little about this, but doesn't have the kernel version info. I swear on hacker news recently someone linked to a library from chromeos that was trying to do syscall wrappers. It looked interesting, but I cannot find it.

https://chromium.googlesource.com/linux-syscall-support/