1 files changed, 27 insertions, 0 deletions

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 96fe2ffd62..f4a02331ff 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -2,6 +2,33 @@ DESCRIPTION = "Sanitized set of kernel headers for the C library's use."
 SECTION = "devel"
 LICENSE = "GPLv2"
 
+#########################################################################
+####                        PLEASE READ 
+#########################################################################
+#
+# You're probably looking here thinking you need to create some new copy
+# of linux-libc-headers since you have your own custom kernel. To put 
+# this simply, you DO NOT.
+#
+# Why? These headers are used to build the libc. If you customise the 
+# headers you are customising the libc and the libc becomes machine
+# specific. Most people do not add custom libc extensions to the kernel
+# and have a machine specific libc.
+#
+# But you have some kernel headers you need for some driver? That is fine
+# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
+# This will make the package using them machine specific but this is much
+# better than having a maching specific C library. This does mean your 
+# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
+# makes total sense.
+#
+# There can also be a case where your kernel extremely old and you want
+# an older libc ABI for that old kernel. The headers installed by this
+# recipe should still be a standard mainline kernel, not your own custom 
+# one.
+#
+# -- RP
+
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
 python __anonymous () {