Lines Matching refs: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
20   * 'external/kernel-headers/original/'
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
38     similarly contains all headers and symlinks to be used on x86
41     to manage and re-generate the headers
47     include Linux headers.
51     the original kernel headers they need.
59     automatically update all clean headers from the content of 
60     'external/kernel-headers/original'. this is the script you're likely going to
61     run whenever you update the original headers.
86 then, add the new architecture-specific headers to original/asm-<arch>.
117 process the original kernel headers into clean ones:
146     macro like CONFIG_FOO from the clean headers.
173   the final pass remove any comments and empty lines from the final headers.
188 The original kernel headers are not easily usable from userland applications.
192 - some headers try to define Posix types (e.g. size_t, ssize_t) that can
195 - some headers use constructs that cannot be compiled in ANSI C mode.
197 - some headers use constructs do not compile with C++ at all.
199 - some headers contain invalid "legacy" definitions for the benefit of old
207 unfortunately, these headers are also the only source of some really extensive
214 headers to be used by userland applications (which installs in
217 scripts. these headers are also tailored to GNU LibC and cannot be reused
222 official headers. from their point of view this is purely a library author
226 install a set of "user-friendly" headers that are generated from the official
233 we plan to be able to support these kernel-generated user-land headers in the
242 clean headers to easily support additional architectures in the future,
247 feel free to randomly break the structure of their headers (e.g. moving the
249 updating our build script/original headers as these cases happen.
251 what we do is keep a set of "original" kernel headers, and process them
252 automatically to generate a set of "clean" headers that can be used from
255 note that the "original" headers can be tweaked a little to avoid some subtle
258 - when the location of various USB-related headers changes in the kernel
260   headers (there is no reason to break the userland API for something