From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 14201E00B6E for ; Thu, 24 Apr 2014 08:57:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKwzWVPGmAcV/2dsb2JhbABZgkIjIU9XxDWBHBZ0gicBAQMSG14BDAkVViYBBBsaiB8BmSOEWa1QF44ng1yBFQSfeItTgzGCKw X-IronPort-AV: E=Sophos;i="4.97,919,1389762000"; d="scan'208,217";a="59465356" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Apr 2014 11:57:16 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Apr 2014 11:41:42 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 11:57:15 -0400 From: "Vuille, Martin (Martin)" To: "yocto@yoctoproject.org" Thread-Topic: Exporting kernel header from patch Thread-Index: Ac9f1VoEjF/wfPWZSACSxkzGYHPoeA== Date: Thu, 24 Apr 2014 15:57:15 +0000 Message-ID: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] MIME-Version: 1.0 Subject: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:57:20 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_30C2D590D16A5C46ADFE65219103779820B77A65AZUS1EXMB03glob_" --_000_30C2D590D16A5C46ADFE65219103779820B77A65AZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a custom layer to add patches to my vendor's BSP layer (based on Linux 3.4, if it matters) and a .bbappend to list the patches. One of the patches adds a header, and this header needs to be exported to the sysroot. I added the following to my .bbappend, based on a discussion I found: do_install_append() { install -d ${D}${includedir}/linux install -m 644 ${S}/include/linux/uc1698u.h ${D}${includedir}/linux/uc1= 698u.h } It "works" (i.e., the header is installed in the sysroot) but there must be more to it than that because I also get a warning about the header being "installed but not shipped in any package". What's the correct way to do this? MV --_000_30C2D590D16A5C46ADFE65219103779820B77A65AZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a custom layer to add patches to my vendor= 217;s BSP layer

(based on Linux 3.4, if it matters) and a .bbappend = to list the

patches.

One of the patches adds a header, and this header ne= eds to

be exported to the sysroot.

I added the following to my .bbappend, based on a di= scussion

I found:

do_install_append() {

install -d ${D}${includedir}/linu= x

install -m 644 ${S}/include/linux= /uc1698u.h ${D}${includedir}/linux/uc1698u.h

}

It “works” (i.e., the header is installe= d in the sysroot) but there must

be more to it than that because I also get a warning= about the header

being “installed but not shipped in any packag= e”.

What’s the correct way to do this?<= /p>

--_000_30C2D590D16A5C46ADFE65219103779820B77A65AZUS1EXMB03glob_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3BCA1E00B75 for ; Thu, 24 Apr 2014 10:32:31 -0700 (PDT) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.5/8.14.5) with ESMTP id s3OHWSXP014222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 10:32:28 -0700 (PDT) Received: from [128.224.56.48] (128.224.56.48) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.169.1; Thu, 24 Apr 2014 10:32:27 -0700 Message-ID: <53594AA0.7020603@windriver.com> Date: Thu, 24 Apr 2014 13:32:16 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Vuille, Martin (Martin)" , "yocto@yoctoproject.org" References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:32:34 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: > I have a custom layer to add patches to my vendor’s BSP layer > > (based on Linux 3.4, if it matters) and a .bbappend to list the > > patches. > > One of the patches adds a header, and this header needs to > > be exported to the sysroot. > > I added the following to my .bbappend, based on a discussion > > I found: > > do_install_append() { > > install -d ${D}${includedir}/linux > > install -m 644 ${S}/include/linux/uc1698u.h > ${D}${includedir}/linux/uc1698u.h > > } > > It “works” (i.e., the header is installed in the sysroot) but there must > > be more to it than that because I also get a warning about the header > > being “installed but not shipped in any package”. > > What’s the correct way to do this? Not answering the question directly, but I can say that kernel's shouldn't be exporting their header files over the sysroot's include/linux/* directory structure, since that is where linux-libc-headers installs and manages the userspace safe headers for the c-library. Sure you are probably installing a new file, and one that doesn't conflict with the existing libc-headers, but as soon as you start working in that directory structure .. you will eventually clobber an existing file. There have been quite a few discussions on this topic over time on the oe-core and yocto lists. Look at the comment in the linux-libc-headers.inc file, and you'll see a note from Richard explaining why this shouldn't be done (searches on the mailing list archives will also find more hits). When you install into the sysroot, the header file should also be in a FILES_ as part of your recipe .. and that is why you are seeing the warning. packaging it would remove the warning, but you'll still have the problem I mention above. The right way is for your application to look at the STAGING_KERNEL_DIR, which will have a copy of that same header file. Alternatively, you can stage your header file at a different sysroot location than include/linux/* and have your application look there. I have an open enhancement that I'm doing for yocto 1.7 which automates the alternate header file structure, but doing it explicitly in your recipes will work for now. Cheers, Bruce > > MV > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B65EBE00B75 for ; Thu, 24 Apr 2014 10:52:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANJOWVPGmAcV/2dsb2JhbABZgmUhgSbEO4EdFnSCJQEBAQECARIoNAYKCwIBCA0IAQIKFAkHMhQRAQEEARIIGogXCAGeD61NF44oOIMkgRUEn3yLVoMxgis X-IronPort-AV: E=Sophos;i="4.97,920,1389762000"; d="scan'208";a="59544078" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Apr 2014 13:52:34 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Apr 2014 13:37:00 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 13:52:33 -0400 From: "Vuille, Martin (Martin)" To: Bruce Ashfield , "yocto@yoctoproject.org" Thread-Topic: [yocto] Exporting kernel header from patch Thread-Index: Ac9f1VoEjF/wfPWZSACSxkzGYHPoeAAL0+oAAAgHaPA= Date: Thu, 24 Apr 2014 17:52:32 +0000 Message-ID: <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> <53594AA0.7020603@windriver.com> In-Reply-To: <53594AA0.7020603@windriver.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] MIME-Version: 1.0 Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:52:36 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com] > Sent: April 24, 2014 1:32 PM >=20 > On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: > > I have a custom layer to add patches to my vendor's BSP layer > > > > (based on Linux 3.4, if it matters) and a .bbappend to list the > > > > patches. > > > > One of the patches adds a header, and this header needs to > > > > be exported to the sysroot. > > > > I added the following to my .bbappend, based on a discussion > > > > I found: > > > > do_install_append() { > > > > install -d ${D}${includedir}/linux > > > > install -m 644 ${S}/include/linux/uc1698u.h > > ${D}${includedir}/linux/uc1698u.h > > > > } > > > > It "works" (i.e., the header is installed in the sysroot) but there > > must > > > > be more to it than that because I also get a warning about the header > > > > being "installed but not shipped in any package". > > > > What's the correct way to do this? >=20 > Not answering the question directly, but I can say that kernel's shouldn'= t be > exporting their header files over the sysroot's > include/linux/* directory structure, since that is where linux-libc-heade= rs > installs and manages the userspace safe headers for the c-library. >=20 > Sure you are probably installing a new file, and one that doesn't conflic= t > with the existing libc-headers, but as soon as you start working in that > directory structure .. you will eventually clobber an existing file. >=20 > There have been quite a few discussions on this topic over time on the oe= - > core and yocto lists. Look at the comment in the linux-libc-headers.inc f= ile, > and you'll see a note from Richard explaining why this shouldn't be done > (searches on the mailing list archives will also find more hits). >=20 > When you install into the sysroot, the header file should also be in a > FILES_ as part of your recipe .. and that is why you are seeing = the > warning. packaging it would remove the warning, but you'll still have the > problem I mention above. >=20 > The right way is for your application to look at the STAGING_KERNEL_DIR, > which will have a copy of that same header file. >=20 > Alternatively, you can stage your header file at a different sysroot loca= tion > than include/linux/* and have your application look there. >=20 > I have an open enhancement that I'm doing for yocto 1.7 which automates > the alternate header file structure, but doing it explicitly in your reci= pes will > work for now. Hi Bruce, Thanks for your response. But I'm afraid I'm not entirely following you. I = am quite new to Yocto/OE, so I may be missing something fundamental/obvious. Leaving aside the patch and .bbappend for the moment, presumably it is normal for the kernel in the BSP layer to export headers for userland's consumption. How is that specified? Where is the FILES_ that lists those headers? MV 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 yocto-www.yoctoproject.org (Postfix) with ESMTP id CE67AE00B75 for ; Thu, 24 Apr 2014 11:01:09 -0700 (PDT) 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.5) with ESMTP id s3OI14tA024312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 11:01:04 -0700 (PDT) Received: from [128.224.56.48] (128.224.56.48) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.169.1; Thu, 24 Apr 2014 11:01:03 -0700 Message-ID: <53595154.4080302@windriver.com> Date: Thu, 24 Apr 2014 14:00:52 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Vuille, Martin (Martin)" , "yocto@yoctoproject.org" References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> <53594AA0.7020603@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:01:12 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote: >> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com] >> Sent: April 24, 2014 1:32 PM >> >> On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: >>> I have a custom layer to add patches to my vendor's BSP layer >>> >>> (based on Linux 3.4, if it matters) and a .bbappend to list the >>> >>> patches. >>> >>> One of the patches adds a header, and this header needs to >>> >>> be exported to the sysroot. >>> >>> I added the following to my .bbappend, based on a discussion >>> >>> I found: >>> >>> do_install_append() { >>> >>> install -d ${D}${includedir}/linux >>> >>> install -m 644 ${S}/include/linux/uc1698u.h >>> ${D}${includedir}/linux/uc1698u.h >>> >>> } >>> >>> It "works" (i.e., the header is installed in the sysroot) but there >>> must >>> >>> be more to it than that because I also get a warning about the header >>> >>> being "installed but not shipped in any package". >>> >>> What's the correct way to do this? >> >> Not answering the question directly, but I can say that kernel's shouldn't be >> exporting their header files over the sysroot's >> include/linux/* directory structure, since that is where linux-libc-headers >> installs and manages the userspace safe headers for the c-library. >> >> Sure you are probably installing a new file, and one that doesn't conflict >> with the existing libc-headers, but as soon as you start working in that >> directory structure .. you will eventually clobber an existing file. >> >> There have been quite a few discussions on this topic over time on the oe- >> core and yocto lists. Look at the comment in the linux-libc-headers.inc file, >> and you'll see a note from Richard explaining why this shouldn't be done >> (searches on the mailing list archives will also find more hits). >> >> When you install into the sysroot, the header file should also be in a >> FILES_ as part of your recipe .. and that is why you are seeing the >> warning. packaging it would remove the warning, but you'll still have the >> problem I mention above. >> >> The right way is for your application to look at the STAGING_KERNEL_DIR, >> which will have a copy of that same header file. >> >> Alternatively, you can stage your header file at a different sysroot location >> than include/linux/* and have your application look there. >> >> I have an open enhancement that I'm doing for yocto 1.7 which automates >> the alternate header file structure, but doing it explicitly in your recipes will >> work for now. > > Hi Bruce, > > Thanks for your response. But I'm afraid I'm not entirely following you. I am > quite new to Yocto/OE, so I may be missing something fundamental/obvious. > > Leaving aside the patch and .bbappend for the moment, presumably it is > normal for the kernel in the BSP layer to export headers for userland's > consumption. How is that specified? Where is the FILES_ that > lists those headers? Actually, in the yocto world, it isn't. At least not in the sense that you are looking for. The kernel's source tree is staged for consumption by other packages in the sysroot, accessible via the variable STAGING_KERNEL_DIR. That's the first choice for an application to look for kernel header files. The sysroots /usr/include/linux/* is strictly for the linux-libc-headers package, and nothing else should be installing into that structure. If you do need to export something to the sysroot, that isn't already in the libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should be installing it to another directory structure like: /usr-alt/include/linux/* and have your applications look there. You'd export and install them similarly to what you are doing, and you'd need to package them similarly. i.e. in the recipe: PACKAGES += " kernel-extra-headers" FILES_kernel-extra-headers = "/usr-alt/linux/*' And you'd get the header in the sysroot, and avoid the QA warning about it not being packaged. Bruce > > MV > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A49D6E00B7C for ; Thu, 24 Apr 2014 12:54:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOxqWVPGmAcV/2dsb2JhbABZgmUhgSbEQ4EfFnSCJQEBAQECARIoNAYKCwIBCA0EBAEBAQoUEDIdCAEBBAESCBqIFwgBngytSheOKDiDJIEVBJ98i1aDMYIr X-IronPort-AV: E=Sophos;i="4.97,921,1389762000"; d="scan'208";a="59501286" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Apr 2014 15:54:05 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Apr 2014 15:38:29 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 15:54:02 -0400 From: "Vuille, Martin (Martin)" To: Bruce Ashfield , "yocto@yoctoproject.org" Thread-Topic: [yocto] Exporting kernel header from patch Thread-Index: Ac9f1VoEjF/wfPWZSACSxkzGYHPoeAAL0+oAAAgHaPD//8fCAIAAJrDg Date: Thu, 24 Apr 2014 19:54:02 +0000 Message-ID: <30C2D590D16A5C46ADFE65219103779820B77AFA@AZ-US1EXMB03.global.avaya.com> References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> <53594AA0.7020603@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> <53595154.4080302@windriver.com> In-Reply-To: <53595154.4080302@windriver.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] MIME-Version: 1.0 Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:54:09 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Bruce Ashfield > Sent: April 24, 2014 2:01 PM > To: Vuille, Martin (Martin); yocto@yoctoproject.org > Subject: Re: [yocto] Exporting kernel header from patch >=20 > On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote: > >> From: Bruce Ashfield > >> Sent: April 24, 2014 1:32 PM > >> > >> On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: > >>> I have a custom layer to add patches to my vendor's BSP layer > >>> > >>> (based on Linux 3.4, if it matters) and a .bbappend to list the > >>> > >>> patches. > >>> > >>> One of the patches adds a header, and this header needs to > >>> > >>> be exported to the sysroot. > >>> > >>> I added the following to my .bbappend, based on a discussion > >>> > >>> I found: > >>> > >>> do_install_append() { > >>> > >>> install -d ${D}${includedir}/linux > >>> > >>> install -m 644 ${S}/include/linux/uc1698u.h > >>> ${D}${includedir}/linux/uc1698u.h > >>> > >>> } > >>> > >>> It "works" (i.e., the header is installed in the sysroot) but there > >>> must > >>> > >>> be more to it than that because I also get a warning about the > >>> header > >>> > >>> being "installed but not shipped in any package". > >>> > >>> What's the correct way to do this? > >> > >> Not answering the question directly, but I can say that kernel's > >> shouldn't be exporting their header files over the sysroot's > >> include/linux/* directory structure, since that is where > >> linux-libc-headers installs and manages the userspace safe headers for > the c-library. > >> > >> Sure you are probably installing a new file, and one that doesn't > >> conflict with the existing libc-headers, but as soon as you start > >> working in that directory structure .. you will eventually clobber an > existing file. > >> > >> There have been quite a few discussions on this topic over time on > >> the oe- core and yocto lists. Look at the comment in the > >> linux-libc-headers.inc file, and you'll see a note from Richard > >> explaining why this shouldn't be done (searches on the mailing list > archives will also find more hits). > >> > >> When you install into the sysroot, the header file should also be in > >> a FILES_ as part of your recipe .. and that is why you are > >> seeing the warning. packaging it would remove the warning, but you'll > >> still have the problem I mention above. > >> > >> The right way is for your application to look at the > >> STAGING_KERNEL_DIR, which will have a copy of that same header file. > >> > >> Alternatively, you can stage your header file at a different sysroot > >> location than include/linux/* and have your application look there. > >> > >> I have an open enhancement that I'm doing for yocto 1.7 which > >> automates the alternate header file structure, but doing it > >> explicitly in your recipes will work for now. > > > > Hi Bruce, > > > > Thanks for your response. But I'm afraid I'm not entirely following > > you. I am quite new to Yocto/OE, so I may be missing something > fundamental/obvious. > > > > Leaving aside the patch and .bbappend for the moment, presumably it is > > normal for the kernel in the BSP layer to export headers for > > userland's consumption. How is that specified? Where is the > > FILES_ that lists those headers? >=20 > Actually, in the yocto world, it isn't. At least not in the sense that yo= u are > looking for. >=20 > The kernel's source tree is staged for consumption by other packages in t= he > sysroot, accessible via the variable STAGING_KERNEL_DIR. That's the first > choice for an application to look for kernel header files. >=20 > The sysroots /usr/include/linux/* is strictly for the linux-libc-headers > package, and nothing else should be installing into that structure. >=20 > If you do need to export something to the sysroot, that isn't already in = the > libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should > be installing it to another directory structure like: > /usr-alt/include/linux/* > and have your applications look there. You'd export and install them > similarly to what you are doing, and you'd need to package them similarly= . >=20 > i.e. in the recipe: >=20 > PACKAGES +=3D " kernel-extra-headers" > FILES_kernel-extra-headers =3D "/usr-alt/linux/*' >=20 > And you'd get the header in the sysroot, and avoid the QA warning about i= t > not being packaged. >=20 I probably should've mentioned earlier that this header contains some ioctl definitions that I need to import into some userland code. If I include the header from STAGING_KERNEL_DIR, isn't that the "raw" header, unprepared for inclusion from userland? (Of course, that was also a problem with my original way of doing it, which I omitted from my OP). What is special about the headers added to sysroot by linux-libc-headers? If this driver were part of upstream instead of added by me, wouldn't its header file be included in the sysroot by linux-libc-headers? I understand that glibc was built against the headers from linux-libc-heade= rs, but that shouldn't matter since no one else but me knows about this new header. Is there a legitimate way for me to add to linux-libc-headers? Apologies if I've gotten myself confused. MV 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 yocto-www.yoctoproject.org (Postfix) with ESMTP id 7F13BE00B7C for ; Thu, 24 Apr 2014 13:05:58 -0700 (PDT) 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.5) with ESMTP id s3OK5tnC015367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 13:05:56 -0700 (PDT) Received: from [128.224.56.48] (128.224.56.48) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.169.1; Thu, 24 Apr 2014 13:05:54 -0700 Message-ID: <53596E97.6010303@windriver.com> Date: Thu, 24 Apr 2014 16:05:43 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Vuille, Martin (Martin)" , "yocto@yoctoproject.org" References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> <53594AA0.7020603@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> <53595154.4080302@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AFA@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <30C2D590D16A5C46ADFE65219103779820B77AFA@AZ-US1EXMB03.global.avaya.com> Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:06:06 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote: >> From: Bruce Ashfield >> Sent: April 24, 2014 2:01 PM >> To: Vuille, Martin (Martin); yocto@yoctoproject.org >> Subject: Re: [yocto] Exporting kernel header from patch >> >> On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote: >>>> From: Bruce Ashfield >>>> Sent: April 24, 2014 1:32 PM >>>> >>>> On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: >>>>> I have a custom layer to add patches to my vendor's BSP layer >>>>> >>>>> (based on Linux 3.4, if it matters) and a .bbappend to list the >>>>> >>>>> patches. >>>>> >>>>> One of the patches adds a header, and this header needs to >>>>> >>>>> be exported to the sysroot. >>>>> >>>>> I added the following to my .bbappend, based on a discussion >>>>> >>>>> I found: >>>>> >>>>> do_install_append() { >>>>> >>>>> install -d ${D}${includedir}/linux >>>>> >>>>> install -m 644 ${S}/include/linux/uc1698u.h >>>>> ${D}${includedir}/linux/uc1698u.h >>>>> >>>>> } >>>>> >>>>> It "works" (i.e., the header is installed in the sysroot) but there >>>>> must >>>>> >>>>> be more to it than that because I also get a warning about the >>>>> header >>>>> >>>>> being "installed but not shipped in any package". >>>>> >>>>> What's the correct way to do this? >>>> >>>> Not answering the question directly, but I can say that kernel's >>>> shouldn't be exporting their header files over the sysroot's >>>> include/linux/* directory structure, since that is where >>>> linux-libc-headers installs and manages the userspace safe headers for >> the c-library. >>>> >>>> Sure you are probably installing a new file, and one that doesn't >>>> conflict with the existing libc-headers, but as soon as you start >>>> working in that directory structure .. you will eventually clobber an >> existing file. >>>> >>>> There have been quite a few discussions on this topic over time on >>>> the oe- core and yocto lists. Look at the comment in the >>>> linux-libc-headers.inc file, and you'll see a note from Richard >>>> explaining why this shouldn't be done (searches on the mailing list >> archives will also find more hits). >>>> >>>> When you install into the sysroot, the header file should also be in >>>> a FILES_ as part of your recipe .. and that is why you are >>>> seeing the warning. packaging it would remove the warning, but you'll >>>> still have the problem I mention above. >>>> >>>> The right way is for your application to look at the >>>> STAGING_KERNEL_DIR, which will have a copy of that same header file. >>>> >>>> Alternatively, you can stage your header file at a different sysroot >>>> location than include/linux/* and have your application look there. >>>> >>>> I have an open enhancement that I'm doing for yocto 1.7 which >>>> automates the alternate header file structure, but doing it >>>> explicitly in your recipes will work for now. >>> >>> Hi Bruce, >>> >>> Thanks for your response. But I'm afraid I'm not entirely following >>> you. I am quite new to Yocto/OE, so I may be missing something >> fundamental/obvious. >>> >>> Leaving aside the patch and .bbappend for the moment, presumably it is >>> normal for the kernel in the BSP layer to export headers for >>> userland's consumption. How is that specified? Where is the >>> FILES_ that lists those headers? >> >> Actually, in the yocto world, it isn't. At least not in the sense that you are >> looking for. >> >> The kernel's source tree is staged for consumption by other packages in the >> sysroot, accessible via the variable STAGING_KERNEL_DIR. That's the first >> choice for an application to look for kernel header files. >> >> The sysroots /usr/include/linux/* is strictly for the linux-libc-headers >> package, and nothing else should be installing into that structure. >> >> If you do need to export something to the sysroot, that isn't already in the >> libc-headers, and you can't use the STAGING_KERNEL_DIR, then you should >> be installing it to another directory structure like: >> /usr-alt/include/linux/* >> and have your applications look there. You'd export and install them >> similarly to what you are doing, and you'd need to package them similarly. >> >> i.e. in the recipe: >> >> PACKAGES += " kernel-extra-headers" >> FILES_kernel-extra-headers = "/usr-alt/linux/*' >> >> And you'd get the header in the sysroot, and avoid the QA warning about it >> not being packaged. >> > > I probably should've mentioned earlier that this header contains some ioctl > definitions that I need to import into some userland code. > > If I include the header from STAGING_KERNEL_DIR, isn't that the "raw" > header, unprepared for inclusion from userland? (Of course, that was also > a problem with my original way of doing it, which I omitted from my OP). Yep, it is the kernel header without having been run through the uapi export. But that doesn't mean it is immediately wrong, applications that know what they are doing can look at headers directly. > > What is special about the headers added to sysroot by linux-libc-headers? > If this driver were part of upstream instead of added by me, wouldn't its > header file be included in the sysroot by linux-libc-headers? Yes it would be, and then it forms part of the released kernel's ABI, and is what the libc interface is based on. It also means that the definitions are consistent across kernels of that same version. If you are patching the kernel to add it, that no longer holds. I assume you found the history and .inc file I pointed out ? They explain a some of what I have above, but maybe not clearly enough. Those exports are special, and are for the c library. They are not for kernel exports to userspace. That's the way the system works, and it is to ensure a sane and santized mapping between the c library and the kernel. board specific exports (which is what you are describing), are done in board specific ways, which I described as the options. When your application is looking for something that is specific to your kernel, the application is by definition board/arch specific, so can depend on the kernel to get the headers that it needs. > > I understand that glibc was built against the headers from linux-libc-headers, > but that shouldn't matter since no one else but me knows about this new > header. It's the slippery slope. Don't install into that structure since someone can inadvertently change a syscall number, function signature, or something else fundamental. I realize you aren't doing that, but eventually someone will .. so simply saying "don't do that", is the right thing to keep the system sane and correct. > > Is there a legitimate way for me to add to linux-libc-headers? You can bbappend and patch the source code. That means that you've considered the change, and want it explicitly exported to userspace via the libc-headers. That will also trigger the libc-headers signature to change and then chain to a full system rebuild (Which is the other reason we simply don't install into the c headers path). Instead of doing that, see my suggestion about installing into an alternate location and have your application put it on it's include path .. a -I is pretty easy to add. Since the application is clearly aware and in need of a special kernel capability, either looking at the source directly, or using that alternate include are not out of the ordinary. Cheers, Bruce > > Apologies if I've gotten myself confused. > > MV > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 1637FE00B7C for ; Thu, 24 Apr 2014 13:18:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANFwWVPGmAcV/2dsb2JhbABZgmUhgSbERIEfFnSCJQEBAQECARIoNAYKCwIBCA0EBAEBAQoUEDIdCAIEARIIGogXCAGeCq1KF44oOIMkgRUEn3yLVoMxgis X-IronPort-AV: E=Sophos;i="4.97,921,1389762000"; d="scan'208";a="59504437" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Apr 2014 16:18:27 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 24 Apr 2014 16:02:53 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 16:18:26 -0400 From: "Vuille, Martin (Martin)" To: Bruce Ashfield , "yocto@yoctoproject.org" Thread-Topic: [yocto] Exporting kernel header from patch Thread-Index: Ac9f1VoEjF/wfPWZSACSxkzGYHPoeAAL0+oAAAgHaPD//8fCAIAAJrDg///8MoCAAD/kkA== Date: Thu, 24 Apr 2014 20:18:26 +0000 Message-ID: <30C2D590D16A5C46ADFE65219103779820B77B18@AZ-US1EXMB03.global.avaya.com> References: <30C2D590D16A5C46ADFE65219103779820B77A65@AZ-US1EXMB03.global.avaya.com> <53594AA0.7020603@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AA1@AZ-US1EXMB03.global.avaya.com> <53595154.4080302@windriver.com> <30C2D590D16A5C46ADFE65219103779820B77AFA@AZ-US1EXMB03.global.avaya.com> <53596E97.6010303@windriver.com> In-Reply-To: <53596E97.6010303@windriver.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] MIME-Version: 1.0 Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:18:29 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Bruce Ashfield > Sent: April 24, 2014 4:06 PM > To: Vuille, Martin (Martin); yocto@yoctoproject.org > Subject: Re: [yocto] Exporting kernel header from patch >=20 > On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote: > >> From: Bruce Ashfield > >> Sent: April 24, 2014 2:01 PM > >> To: Vuille, Martin (Martin); yocto@yoctoproject.org > >> Subject: Re: [yocto] Exporting kernel header from patch > >> > >> On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote: > >>>> From: Bruce Ashfield > >>>> Sent: April 24, 2014 1:32 PM > >>>> > >>>> On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote: > >>>>> I have a custom layer to add patches to my vendor's BSP layer > >>>>> > >>>>> (based on Linux 3.4, if it matters) and a .bbappend to list the > >>>>> > >>>>> patches. > >>>>> > >>>>> One of the patches adds a header, and this header needs to > >>>>> > >>>>> be exported to the sysroot. > >>>>> > >>>>> I added the following to my .bbappend, based on a discussion > >>>>> > >>>>> I found: > >>>>> > >>>>> do_install_append() { > >>>>> > >>>>> install -d ${D}${includedir}/linux > >>>>> > >>>>> install -m 644 ${S}/include/linux/uc1698u.h > >>>>> ${D}${includedir}/linux/uc1698u.h > >>>>> > >>>>> } > >>>>> > >>>>> It "works" (i.e., the header is installed in the sysroot) but > >>>>> there must > >>>>> > >>>>> be more to it than that because I also get a warning about the > >>>>> header > >>>>> > >>>>> being "installed but not shipped in any package". > >>>>> > >>>>> What's the correct way to do this? > >>>> > >>>> Not answering the question directly, but I can say that kernel's > >>>> shouldn't be exporting their header files over the sysroot's > >>>> include/linux/* directory structure, since that is where > >>>> linux-libc-headers installs and manages the userspace safe headers > >>>> for > >> the c-library. > >>>> > >>>> Sure you are probably installing a new file, and one that doesn't > >>>> conflict with the existing libc-headers, but as soon as you start > >>>> working in that directory structure .. you will eventually clobber > >>>> an > >> existing file. > >>>> > >>>> There have been quite a few discussions on this topic over time on > >>>> the oe- core and yocto lists. Look at the comment in the > >>>> linux-libc-headers.inc file, and you'll see a note from Richard > >>>> explaining why this shouldn't be done (searches on the mailing list > >> archives will also find more hits). > >>>> > >>>> When you install into the sysroot, the header file should also be > >>>> in a FILES_ as part of your recipe .. and that is why you > >>>> are seeing the warning. packaging it would remove the warning, but > >>>> you'll still have the problem I mention above. > >>>> > >>>> The right way is for your application to look at the > >>>> STAGING_KERNEL_DIR, which will have a copy of that same header file. > >>>> > >>>> Alternatively, you can stage your header file at a different > >>>> sysroot location than include/linux/* and have your application look > there. > >>>> > >>>> I have an open enhancement that I'm doing for yocto 1.7 which > >>>> automates the alternate header file structure, but doing it > >>>> explicitly in your recipes will work for now. > >>> > >>> Hi Bruce, > >>> > >>> Thanks for your response. But I'm afraid I'm not entirely following > >>> you. I am quite new to Yocto/OE, so I may be missing something > >> fundamental/obvious. > >>> > >>> Leaving aside the patch and .bbappend for the moment, presumably it > >>> is normal for the kernel in the BSP layer to export headers for > >>> userland's consumption. How is that specified? Where is the > >>> FILES_ that lists those headers? > >> > >> Actually, in the yocto world, it isn't. At least not in the sense > >> that you are looking for. > >> > >> The kernel's source tree is staged for consumption by other packages > >> in the sysroot, accessible via the variable STAGING_KERNEL_DIR. > >> That's the first choice for an application to look for kernel header f= iles. > >> > >> The sysroots /usr/include/linux/* is strictly for the > >> linux-libc-headers package, and nothing else should be installing into > that structure. > >> > >> If you do need to export something to the sysroot, that isn't already > >> in the libc-headers, and you can't use the STAGING_KERNEL_DIR, then > >> you should be installing it to another directory structure like: > >> /usr-alt/include/linux/* > >> and have your applications look there. You'd export and install them > >> similarly to what you are doing, and you'd need to package them > similarly. > >> > >> i.e. in the recipe: > >> > >> PACKAGES +=3D " kernel-extra-headers" > >> FILES_kernel-extra-headers =3D "/usr-alt/linux/*' > >> > >> And you'd get the header in the sysroot, and avoid the QA warning > >> about it not being packaged. > >> > > > > I probably should've mentioned earlier that this header contains some > > ioctl definitions that I need to import into some userland code. > > > > If I include the header from STAGING_KERNEL_DIR, isn't that the "raw" > > header, unprepared for inclusion from userland? (Of course, that was > > also a problem with my original way of doing it, which I omitted from m= y > OP). >=20 > Yep, it is the kernel header without having been run through the uapi > export. But that doesn't mean it is immediately wrong, applications that > know what they are doing can look at headers directly. >=20 > > > > What is special about the headers added to sysroot by linux-libc-header= s? > > If this driver were part of upstream instead of added by me, wouldn't > > its header file be included in the sysroot by linux-libc-headers? >=20 > Yes it would be, and then it forms part of the released kernel's ABI, and= is > what the libc interface is based on. It also means that the definitions a= re > consistent across kernels of that same version. If you are patching the > kernel to add it, that no longer holds. >=20 > I assume you found the history and .inc file I pointed out ? They explain= a > some of what I have above, but maybe not clearly enough. Those exports > are special, and are for the c library. They are not for kernel exports t= o > userspace. That's the way the system works, and it is to ensure a sane an= d > santized mapping between the c library and the kernel. >=20 > board specific exports (which is what you are describing), are done in bo= ard > specific ways, which I described as the options. When your application is > looking for something that is specific to your kernel, the application is= by > definition board/arch specific, so can depend on the kernel to get the > headers that it needs. >=20 > > > > I understand that glibc was built against the headers from > > linux-libc-headers, but that shouldn't matter since no one else but me > > knows about this new header. >=20 > It's the slippery slope. Don't install into that structure since someone = can > inadvertently change a syscall number, function signature, or something > else fundamental. >=20 > I realize you aren't doing that, but eventually someone will .. so simply > saying "don't do that", is the right thing to keep the system sane and co= rrect. >=20 > > > > Is there a legitimate way for me to add to linux-libc-headers? >=20 > You can bbappend and patch the source code. That means that you've > considered the change, and want it explicitly exported to userspace via t= he > libc-headers. That will also trigger the libc-headers signature to change= and > then chain to a full system rebuild (Which is the other reason we simply > don't install into the c headers path). >=20 > Instead of doing that, see my suggestion about installing into an alterna= te > location and have your application put it on it's include path .. a -I is= pretty > easy to add. Since the application is clearly aware and in need of a spec= ial > kernel capability, either looking at the source directly, or using that > alternate include are not out of the ordinary. >=20 Thanks for the detailed explanation. I will head in the direction of a sepa= rate location for that (and any other board-specific) headers. MV From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 19007E00927; Wed, 22 Jul 2015 08:10:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [68.232.130.217 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message X-Greylist: delayed 64 seconds by postgrey-1.32 at yocto-www; Wed, 22 Jul 2015 08:10:50 PDT Received: from esa1.emerson-outbound.iphmx.com (esa1.emerson-outbound.iphmx.com [68.232.130.217]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A0049E008EC for ; Wed, 22 Jul 2015 08:10:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,523,1432576800"; d="scan'208,217";a="13035788" Received: from usstlz-pinfez05.extemr.org ([144.191.128.189]) by esa1.emerson-outbound.iphmx.com with ESMTP/TLS/AES128-SHA; 22 Jul 2015 21:09:44 +0600 Received: from USSTLZ-PMSG015.emrsn.org (10.16.72.197) by USSTLZ-PINFEZ05.extemr.org (10.16.8.78) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jul 2015 15:09:27 +0000 Received: from USSTLZ-PMSG016.emrsn.org ([169.254.8.133]) by USSTLZ-PMSG015.emrsn.org ([169.254.7.101]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 15:09:27 +0000 From: To: Thread-Topic: Re: [yocto] Exporting kernel header from patch Thread-Index: AdDEj9S9XdwaQlrYRxG6+34ksITjOQ== Date: Wed, 22 Jul 2015 15:09:26 +0000 Message-ID: <5B6A9B05AFA9AC4FB94345D083806F144B2BF945@USSTLZ-PMSG016.emrsn.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.249.11] MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 Jul 2015 14:34:49 -0700 Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:10:52 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5B6A9B05AFA9AC4FB94345D083806F144B2BF945USSTLZPMSG016em_" --_000_5B6A9B05AFA9AC4FB94345D083806F144B2BF945USSTLZPMSG016em_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When using a shared sstate cache which has the previously built kernel it a= ppears that STAGING_KERNEL_DIR does not get populated - in my case there is= no tmp/work-shared directory at all. If I have modified the user space ap= p to look there for a header is there some dependency I can add that will f= orce STAGING_KERNEL_DIR to get built? If not, perhaps the best answer is your other proposed method of just addin= g the header to an additional path in sysroot. --_000_5B6A9B05AFA9AC4FB94345D083806F144B2BF945USSTLZPMSG016em_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When using a shared sstate cache which has the previ= ously built kernel it appears that STAGING_KERNEL_DIR does not get populate= d – in my case there is no tmp/work-shared directory at all. If= I have modified the user space app to look there for a header is there some dependency I can add that will force STAGING_KE= RNEL_DIR to get built?

If not, perhaps the best answer is your other propos= ed method of just adding the header to an additional path in sysroot.<= /o:p>

--_000_5B6A9B05AFA9AC4FB94345D083806F144B2BF945USSTLZPMSG016em_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id C467FE008D4; Wed, 22 Jul 2015 18:03:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (danielhilst[at]gmail.com) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.192.45 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 375B4E00474 for ; Wed, 22 Jul 2015 18:03:14 -0700 (PDT) Received: by qgii95 with SMTP id i95so80159110qgi.2 for ; Wed, 22 Jul 2015 18:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K0TLEO7zUuuHbb3fjzlrcurdbU9gTMUMRdABFXTPYFo=; b=GQXvDOyXeRnl85SvdCqIdsVfuIu/najWN7HryqyW/eTjVqmSi4Z+H54cFNXJYnEYzk kvqYgQnegCKSDU4hgpBDQ5hzoDHhvmtE0t/m6vKlHBeaotL8XJcsAca2vgbqFWqSM0Li V9NpPO8PUqGQWHvze3pR3nHOfnwf/R8P2ZZxwOhAGoWjCVfNIGtW2EvCi+2IEHbGAoBW DQePiy45uCCUkeArLuWJkFvWgUF91sclH5KXo3iiPi3FrLvnF5uGzeF6KXaL+1QG16S1 PccQ88qqQr9vl57Dkxh8cjBwPtLgUgS2gFwoYhoYoPsG29pUejI9acNT/aqJkWokRGqV op/g== MIME-Version: 1.0 X-Received: by 10.140.239.9 with SMTP id k9mr8561036qhc.38.1437613394330; Wed, 22 Jul 2015 18:03:14 -0700 (PDT) Received: by 10.96.179.74 with HTTP; Wed, 22 Jul 2015 18:03:14 -0700 (PDT) Received: by 10.96.179.74 with HTTP; Wed, 22 Jul 2015 18:03:14 -0700 (PDT) In-Reply-To: References: <5B6A9B05AFA9AC4FB94345D083806F144B2BF945@USSTLZ-PMSG016.emrsn.org> Date: Wed, 22 Jul 2015 22:03:14 -0300 Message-ID: From: "Daniel." To: Gamma.Dean@emerson.com Cc: yocto@yoctoproject.org Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 01:03:15 -0000 Content-Type: multipart/alternative; boundary=001a113593a6b18dcb051b80737f --001a113593a6b18dcb051b80737f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a guess, Did you have INHERIT +=3D "rm_work" in your local.conf? Cheers, - dhs Em 22/07/2015 18:36, escreveu: When using a shared sstate cache which has the previously built kernel it appears that STAGING_KERNEL_DIR does not get populated =E2=80=93 in my case= there is no tmp/work-shared directory at all. If I have modified the user space app to look there for a header is there some dependency I can add that will force STAGING_KERNEL_DIR to get built? If not, perhaps the best answer is your other proposed method of just adding the header to an additional path in sysroot. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto --001a113593a6b18dcb051b80737f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just a guess,

Did you have INHERIT +=3D "rm_work" in your local.= conf?

Cheers,
- dhs

Em 22/07/2015 18:36, <Gamma.Dean@emerson.com> escreveu:

When using a shared sstate cache which has the previ= ously built kernel it appears that STAGING_KERNEL_DIR does not get populate= d =E2=80=93 in my case there is no tmp/work-shared directory at all.=C2=A0 = If I have modified the user space app to look there for a header is there some dependency I can add that will force STAGING_KE= RNEL_DIR to get built?

=C2=A0

If not, perhaps the best answer is your other propos= ed method of just adding the header to an additional path in sysroot.

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

--001a113593a6b18dcb051b80737f-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 76F87E009B3; Thu, 23 Jul 2015 10:55:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [68.232.143.91 listed in list.dnswl.org] X-Greylist: delayed 64 seconds by postgrey-1.32 at yocto-www; Thu, 23 Jul 2015 10:55:11 PDT Received: from esa5.emerson-outbound.iphmx.com (esa5.emerson-outbound.iphmx.com [68.232.143.91]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 37A29E0087F for ; Thu, 23 Jul 2015 10:55:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,532,1432598400"; d="scan'208,217";a="12529411" Received: from usstlz-pinfez08.extemr.org ([144.191.128.192]) by esa5.emerson-outbound.iphmx.com with ESMTP/TLS/AES128-SHA; 23 Jul 2015 17:54:06 +0000 Received: from USSTLZ-PMSG004.emrsn.org (10.16.72.186) by USSTLZ-PINFEZ08.extemr.org (10.16.8.81) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jul 2015 17:54:06 +0000 Received: from USSTLZ-PMSG016.emrsn.org ([169.254.8.133]) by USSTLZ-PMSG004.emrsn.org ([169.254.8.96]) with mapi id 14.03.0158.001; Thu, 23 Jul 2015 17:54:05 +0000 From: To: Thread-Topic: [yocto] Exporting kernel header from patch Thread-Index: AQHQxONZhvoLQsZeQgK+7f8U+Rof/J3pVlUQ Date: Thu, 23 Jul 2015 17:54:06 +0000 Message-ID: <5B6A9B05AFA9AC4FB94345D083806F144B2BFEC2@USSTLZ-PMSG016.emrsn.org> References: <5B6A9B05AFA9AC4FB94345D083806F144B2BF945@USSTLZ-PMSG016.emrsn.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.249.11] MIME-Version: 1.0 Cc: yocto@yoctoproject.org Subject: Re: Exporting kernel header from patch X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 17:55:14 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5B6A9B05AFA9AC4FB94345D083806F144B2BFEC2USSTLZPMSG016em_" --_000_5B6A9B05AFA9AC4FB94345D083806F144B2BFEC2USSTLZPMSG016em_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaWRu4oCZdCBmaW5kIOKAnHJtX3dvcmvigJ0gaW4gYW55IG9mIG15IGNvbmYgZmlsZXMgc28g SSBkb27igJl0IHRoaW5rIHRoYXTigJlzIHRoZSBpc3N1ZS4NCg0KSXQgYXBwZWFycyB0aGF0IFNU QUdJTkdfS0VSTkVMX0RJUiBqdXN0IGRvZXNu4oCZdCBnZXQgcmVidWlsdCBmcm9tIHNzdGF0ZSB3 aGljaCBJIGNhbiB1bmRlcnN0YW5kIHNpbmNlIGl0IGlzbuKAmXQgbmVlZGVkIGJ5IGRlZmF1bHQu ICBJIGZvdW5kIGEgd2F5IHRvIHNldCB1cCB0aGUgZGVwZW5kZW5jaWVzIHRvIGJ1aWxkIGl0IHdo ZW4gbmVlZGVkIGFuZCBJIHN0YXJ0ZWQgYSBuZXcgdGhyZWFkIG92ZXIgb24gdGhlIG9lLWNvcmUg bGlzdCB0aXRsZWQg4oCcUmVidWlsZGluZyBTVEFHSU5HX0tFUk5FTF9ESVIgZnJvbSBzc3RhdGUg Y2FjaGXigJ0gcmVnYXJkaW5nIHRoYXQuDQoNClRoYW5rcyENCg0KRnJvbTogRGFuaWVsLiBbbWFp bHRvOmRhbmllbGhpbHN0QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMiwgMjAx NSA5OjAzIFBNDQpUbzogRGVhbiwgR2FtbWEgW05FVFBXUi9GTF0NCkNjOiB5b2N0b0B5b2N0b3By b2plY3Qub3JnDQpTdWJqZWN0OiBSZTogW3lvY3RvXSBFeHBvcnRpbmcga2VybmVsIGhlYWRlciBm cm9tIHBhdGNoDQoNCg0KSnVzdCBhIGd1ZXNzLA0KDQpEaWQgeW91IGhhdmUgSU5IRVJJVCArPSAi cm1fd29yayIgaW4geW91ciBsb2NhbC5jb25mPw0KDQpDaGVlcnMsDQotIGRocw0KRW0gMjIvMDcv MjAxNSAxODozNiwgPEdhbW1hLkRlYW5AZW1lcnNvbi5jb208bWFpbHRvOkdhbW1hLkRlYW5AZW1l cnNvbi5jb20+PiBlc2NyZXZldToNCldoZW4gdXNpbmcgYSBzaGFyZWQgc3N0YXRlIGNhY2hlIHdo aWNoIGhhcyB0aGUgcHJldmlvdXNseSBidWlsdCBrZXJuZWwgaXQgYXBwZWFycyB0aGF0IFNUQUdJ TkdfS0VSTkVMX0RJUiBkb2VzIG5vdCBnZXQgcG9wdWxhdGVkIOKAkyBpbiBteSBjYXNlIHRoZXJl IGlzIG5vIHRtcC93b3JrLXNoYXJlZCBkaXJlY3RvcnkgYXQgYWxsLiAgSWYgSSBoYXZlIG1vZGlm aWVkIHRoZSB1c2VyIHNwYWNlIGFwcCB0byBsb29rIHRoZXJlIGZvciBhIGhlYWRlciBpcyB0aGVy ZSBzb21lIGRlcGVuZGVuY3kgSSBjYW4gYWRkIHRoYXQgd2lsbCBmb3JjZSBTVEFHSU5HX0tFUk5F TF9ESVIgdG8gZ2V0IGJ1aWx0Pw0KDQpJZiBub3QsIHBlcmhhcHMgdGhlIGJlc3QgYW5zd2VyIGlz IHlvdXIgb3RoZXIgcHJvcG9zZWQgbWV0aG9kIG9mIGp1c3QgYWRkaW5nIHRoZSBoZWFkZXIgdG8g YW4gYWRkaXRpb25hbCBwYXRoIGluIHN5c3Jvb3QuDQoNCi0tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KeW9jdG8gbWFpbGluZyBsaXN0DQp5b2N0b0B5 b2N0b3Byb2plY3Qub3JnPG1haWx0bzp5b2N0b0B5b2N0b3Byb2plY3Qub3JnPg0KaHR0cHM6Ly9s aXN0cy55b2N0b3Byb2plY3Qub3JnL2xpc3RpbmZvL3lvY3RvDQo= --_000_5B6A9B05AFA9AC4FB94345D083806F144B2BFEC2USSTLZPMSG016em_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgZGlkbuKAmXQgZmluZCDigJxybV93b3Jr4oCdIGluIGFueSBvZiBteSBjb25mIGZpbGVzIHNv IEkgZG9u4oCZdCB0aGluayB0aGF04oCZcyB0aGUgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBhcHBlYXJz IHRoYXQgU1RBR0lOR19LRVJORUxfRElSIGp1c3QgZG9lc27igJl0IGdldCByZWJ1aWx0IGZyb20g c3N0YXRlIHdoaWNoIEkgY2FuIHVuZGVyc3RhbmQgc2luY2UgaXQgaXNu4oCZdCBuZWVkZWQgYnkg ZGVmYXVsdC4mbmJzcDsgSSBmb3VuZCBhIHdheSB0byBzZXQgdXAgdGhlDQogZGVwZW5kZW5jaWVz IHRvIGJ1aWxkIGl0IHdoZW4gbmVlZGVkIGFuZCBJIHN0YXJ0ZWQgYSBuZXcgdGhyZWFkIG92ZXIg b24gdGhlIG9lLWNvcmUgbGlzdCB0aXRsZWQg4oCcUmVidWlsZGluZyBTVEFHSU5HX0tFUk5FTF9E SVIgZnJvbSBzc3RhdGUgY2FjaGXigJ0gcmVnYXJkaW5nIHRoYXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mh PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYW5pZWwuIFttYWls dG86ZGFuaWVsaGlsc3RAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SnVseSAyMiwgMjAxNSA5OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBEZWFuLCBHYW1tYSBbTkVUUFdS L0ZMXTxicj4NCjxiPkNjOjwvYj4geW9jdG9AeW9jdG9wcm9qZWN0Lm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3lvY3RvXSBFeHBvcnRpbmcga2VybmVsIGhlYWRlciBmcm9tIHBhdGNoPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cD5KdXN0IGEgZ3Vlc3MsPG86cD48L286cD48L3A+DQo8cD5EaWQgeW91IGhhdmUg SU5IRVJJVCAmIzQzOz0gJnF1b3Q7cm1fd29yayZxdW90OyBpbiB5b3VyIGxvY2FsLmNvbmY/PG86 cD48L286cD48L3A+DQo8cD5DaGVlcnMsPGJyPg0KLSBkaHM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbSAyMi8wNy8yMDE1IDE4OjM2LCAmbHQ7PGEgaHJlZj0i bWFpbHRvOkdhbW1hLkRlYW5AZW1lcnNvbi5jb20iPkdhbW1hLkRlYW5AZW1lcnNvbi5jb208L2E+ Jmd0OyBlc2NyZXZldTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XaGVuIHVzaW5nIGEgc2hhcmVkIHNzdGF0ZSBjYWNoZSB3aGljaCBoYXMgdGhl IHByZXZpb3VzbHkgYnVpbHQga2VybmVsIGl0IGFwcGVhcnMgdGhhdCBTVEFHSU5HX0tFUk5FTF9E SVIgZG9lcyBub3QgZ2V0IHBvcHVsYXRlZCDigJMgaW4gbXkgY2FzZSB0aGVyZSBpcyBubyB0bXAv d29yay1zaGFyZWQgZGlyZWN0b3J5DQogYXQgYWxsLiZuYnNwOyBJZiBJIGhhdmUgbW9kaWZpZWQg dGhlIHVzZXIgc3BhY2UgYXBwIHRvIGxvb2sgdGhlcmUgZm9yIGEgaGVhZGVyIGlzIHRoZXJlIHNv bWUgZGVwZW5kZW5jeSBJIGNhbiBhZGQgdGhhdCB3aWxsIGZvcmNlIFNUQUdJTkdfS0VSTkVMX0RJ UiB0byBnZXQgYnVpbHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBub3QsIHBlcmhh cHMgdGhlIGJlc3QgYW5zd2VyIGlzIHlvdXIgb3RoZXIgcHJvcG9zZWQgbWV0aG9kIG9mIGp1c3Qg YWRkaW5nIHRoZSBoZWFkZXIgdG8gYW4gYWRkaXRpb25hbCBwYXRoIGluIHN5c3Jvb3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQotLTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KeW9jdG8gbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnlvY3RvQHlvY3RvcHJvamVjdC5vcmciPnlvY3RvQHlvY3RvcHJvamVjdC5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9saXN0cy55b2N0b3Byb2plY3Qub3JnL2xpc3Rp bmZvL3lvY3RvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9saXN0cy55b2N0b3Byb2plY3Qub3Jn L2xpc3RpbmZvL3lvY3RvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_5B6A9B05AFA9AC4FB94345D083806F144B2BFEC2USSTLZPMSG016em_--