From beb301c03afa600214bd54753ddc7d60a953c8c4 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 4 Apr 2017 14:20:48 -0700 Subject: dev-manual: Added section on using headers to interface with devices Fixes [YOCTO #8596] Added a new section to describe the right way to use headers to interface to a device or custom Linux kernel API. Too often a user wants to modify the libc header file, which absolutely wrong. This new section provides some guidance. (From yocto-docs rev: 960c49bf6446398a9efb2d018d09d63b49e97196) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 87 ++++++++++++++++++++++ 1 file changed, 87 insertions(+) (limited to 'documentation') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index f9b2910578..a6e14bb93c 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -2691,6 +2691,93 @@ +
+ Using Headers to Interface with Devices + + + If your recipe builds an application that needs to + communicate with some device or needs an API into a custom + kernel, you will need to provide appropriate header files. + Under no circumstances should you ever modify the existing + meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc + file. + These headers are used to build libc and + must not be compromised with custom or machine-specific + header information. + If you customize libc through modified + headers all other applications that use + libc thus become affected. + Warning + Never copy and customize the libc + header file (i.e. + meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc). + + The correct way to interface to a device or custom kernel is + to use a separate package that provides the additional headers + for the driver or other unique interfaces. + When doing so, your application also becomes responsible for + creating a dependency on that specific provider. + + + + Consider the following: + + + Never modify + linux-libc-headers.inc. + Consider that file to be part of the + libc system, and not something + you use to access the kernel directly. + You should access libc through + specific libc calls. + + + Applications that must talk directly to devices + should either provide necessary headers themselves, + or establish a dependency on a special headers package + that is specific to that driver. + + + + + + For example, suppose you want to modify an existing header + that adds I/O control or network support. + If the modifications are used by a small number programs, + providing a unique version of a header is easy and has little + impact. + When doing so, bear in mind the guidelines in the previous + list. + + If for some reason your changes need to modify the behavior + of the libc, and subsequently all + other applications on the system, use a + .bbappend to modify the + linux-kernel-headers.inc file. + However, take care to not make the changes + machine specific. + + + + + Consider a case where your kernel is older and you need + an older libc ABI. + The headers installed by your recipe should still be a + standard mainline kernel, not your own custom one. + + + + When you use custom kernel headers you need to get them from + STAGING_KERNEL_DIR, + which is the directory with kernel headers that are + required to build out-of-tree modules. + Your recipe will also need the following: + + do_configure[depends] += "virtual/kernel:do_shared_workdir" + + +
+
Compilation -- cgit v1.2.3-54-g00ecf