Lines Matching full:headers
1 Bionic comes with a set of 'clean' Linux kernel headers that can safely be
6 these clean headers are automatically generated by several scripts located
8 and unmodified kernel headers in order to get rid of many annoying
11 the 'clean headers' only contain type and macro definitions, with the
21 contains a set of kernel headers as normally found in the 'include'
27 contains the non-arch-specific clean headers and directories
31 contains the ARM-specific directory tree of clean headers.
34 contains the real ARM-specific headers
37 similarly contains all headers and symlinks to be used on x86
40 to manage and re-generate the headers
46 include Linux headers.
50 the original kernel headers they need.
58 automatically update all clean headers from the content of
60 run whenever you update the original headers.
70 HOW TO BUILD BIONIC AND OTHER PROGRAMS WITH THE CLEAN HEADERS:
92 then, add the new architecture-specific headers to original/asm-<arch>.
99 HOW TO UPDATE THE HEADERS WHEN NEEDED:
104 WHEN UPDATING THE HEADERS, ALWAYS CHECK THAT THE NEW CLEAN HEADERS DO
123 process the original kernel headers into clean ones:
152 macro like CONFIG_FOO from the clean headers.
179 the final pass remove any comments and empty lines from the final headers.
194 The original kernel headers are not easily usable from userland applications.
198 - some headers try to define Posix types (e.g. size_t, ssize_t) that can
201 - some headers use constructs that cannot be compiled in ANSI C mode.
203 - some headers use constructs do not compile with C++ at all.
205 - some headers contain invalid "legacy" definitions for the benefit of old
213 unfortunately, these headers are also the only source of some really extensive
220 headers to be used by userland applications (which installs in
223 scripts. these headers are also tailored to GNU LibC and cannot be reused
228 official headers. from their point of view this is purely a library author
232 install a set of "user-friendly" headers that are generated from the official
239 we plan to be able to support these kernel-generated user-land headers in the
248 clean headers to easily support additional architectures in the future,
253 feel free to randomly break the structure of their headers (e.g. moving the
255 updating our build script/original headers as these cases happen.
257 what we do is keep a set of "original" kernel headers, and process them
258 automatically to generate a set of "clean" headers that can be used from
261 note that the "original" headers can be tweaked a little to avoid some subtle
264 - when the location of various USB-related headers changes in the kernel
266 headers (there is no reason to break the userland API for something
