From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id A0EB16CC05 for ; Wed, 2 Oct 2013 13:56:38 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r92DuWTP027188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 06:56:32 -0700 (PDT) Received: from [128.224.146.67] (128.224.146.67) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.347.0; Wed, 2 Oct 2013 06:56:31 -0700 Message-ID: <524C260C.6040507@windriver.com> Date: Wed, 2 Oct 2013 09:56:28 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Peter Kjellerstedt , "OE Core (openembedded-core@lists.openembedded.org)" References: In-Reply-To: Cc: "Darren Hart \(dvhart@linux.intel.com\)" Subject: Re: Sanitized kernel headers X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:56:39 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 13-10-02 09:45 AM, Peter Kjellerstedt wrote: > In a recent commit > (http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72), > Richard added a big warning about not forking the > linux-libc-headers recipe to get at specific kernel > headers for user space. As a consequence I thought I > should remove our fork of linux-libc-headers and instead > use the suggested method of including the needed files > from ${STAGING_KERNEL_DIR} in the recipes that need them. > > However, I soon realized that what I need are the sanitized > headers that are generated by running "make headers_install" > in the kernel sources. So what I then did was to create a > simple bbclass that generates them for me and makes them > available for my recipe: > > ---- %< ------------- kernel-headers.bbclass -------------- > DEPENDS += "virtual/kernel" > > PACKAGE_ARCH = "${MACHINE_ARCH}" > > inherit kernel-arch > > KINCLUDES ?= "${WORKDIR}/kernel-includes" > > do_compile_prepend() { > mkdir -p ${KINCLUDES} > oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES} > } > --------------------------------------------------- >% ---- > > After that I could simply do 'inherit kernel-headers' and > 'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get > at the sanitized kernel headers. > > But, it seems somewhat wasteful for each recipe that need > those headers to do that. Wouldn't it be an idea to provide > the sanitized headers in ${STAGING_KERNEL_DIR}/usr/include > (which would be the default path for make headers_install) > by default? For developers already comfortable with using a previously forked libc-headers, I don't see much of a problem. There of course is still a potential issue if these parallel, machine specific headers are generated from a kernel tree that modifies files which are already exported and made available via the libc-headers package. That being said, the risk is actually less in this situation, since a different include path is required, hence an explicit acknowledgment that something not quite standard is happening. I've proposed similar solutions in the past, including installing the headers into the sysroot along side of the libc-headers in "usr-alt/", or "kernel-headers/", rather than within the kernel staging dir, since the staging dir is often tar'd up and added to things like the kernel-dev package or SDKs .. and if not properly installed, you can clash with the libc usr/include/linux headers. But yes, either way, I'm all for doing this once, making them available in a oe-core "standard" location, as long as it isn't picked up by default include paths. If you want to open up something in the bugzilla, we can take care of this early in the yocto 1.6 cycle, since at this point in 1.5, we don't want to jiggle much of anything :) Cheers, Bruce > > //Peter >