from:"He Zhe"

Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-23 Thread He Zhe

Ping.

On 07/21/2015 03:23 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
>  - To support building packaging and installing multi types of kernel
>images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>as a list.
>  - Modify wherever reference KERNEL_IMAGETYPE accordingly.
>  - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>depending on build machine's, when KEEPUIMAGE is "yes".
>  - v2: update with the latest oe-core
>
> He Zhe (2):
>   kernel: Define KERNEL_IMAGETYPE as a list
>   kernel: Pass sysroot mkimage to kernel makefile
>
>  meta/classes/image_types.bbclass |   6 +-
>  meta/classes/kernel-fitimage.bbclass |  22 +++---
>  meta/classes/kernel-grub.bbclass |  47 
>  meta/classes/kernel-uimage.bbclass   |  31 +---
>  meta/classes/kernel.bbclass  | 127 
> ++-
>  meta/conf/documentation.conf |   2 +-
>  meta/lib/oeqa/controllers/masterimage.py |   2 +-
>  meta/lib/oeqa/targetcontrol.py   |   2 +-
>  meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
>  scripts/test-remote-image|   2 +-
>  10 files changed, 175 insertions(+), 81 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] kernel: Pass sysroot mkimage to kernel makefile

2015-07-24 Thread He Zhe



On 07/23/2015 11:55 PM, Richard Purdie wrote:
> On Tue, 2015-07-21 at 15:23 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>> depending on build machine's when KEEPUIMAGE is "yes".
>>
>> Fixes [YOCTO #6945].
>>
>> Signed-off-by: He Zhe 
>> ---
>>  meta/classes/kernel.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 86ed28f..1d7fa48 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -141,7 +141,7 @@ UBOOT_ENTRYPOINT ?= "20008000"
>>  UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
>>  
>>  # Some Linux kernel configurations need additional parameters on the 
>> command line
>> -KERNEL_EXTRA_ARGS ?= ""
>> +KERNEL_EXTRA_ARGS ?= "NATIVE_MKIMAGE=${STAGING_BINDIR_NATIVE}/mkimage"
>>  
>>  # For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE.
>>  # We don't want to override kernel Makefile variables from the environment
> ${STAGING_BINDIR_NATIVE} should be in PATH ahead of the usual system
> paths. Why therefore is this necessary? Is something resetting PATH?

You are right. There's no need to modify KERNEL_EXTRA_ARGS. Actually I made a 
mistake when I verified mkimage... I'll delete this patch in next version. 
Thank you for reviewing.

BTW, what about [PATCH v2 1/2] ?


Zhe

> Cheers,
>
> Richard
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-26 Thread He Zhe

Ping.

On 07/23/2015 03:48 PM, He Zhe wrote:
> Ping.
>
> On 07/21/2015 03:23 PM, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>>  - To support building packaging and installing multi types of kernel
>>images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>>as a list.
>>  - Modify wherever reference KERNEL_IMAGETYPE accordingly.
>>  - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>>depending on build machine's, when KEEPUIMAGE is "yes".
>>  - v2: update with the latest oe-core
>>
>> He Zhe (2):
>>   kernel: Define KERNEL_IMAGETYPE as a list
>>   kernel: Pass sysroot mkimage to kernel makefile
>>
>>  meta/classes/image_types.bbclass |   6 +-
>>  meta/classes/kernel-fitimage.bbclass |  22 +++---
>>  meta/classes/kernel-grub.bbclass |  47 
>>  meta/classes/kernel-uimage.bbclass   |  31 +---
>>  meta/classes/kernel.bbclass  | 127 
>> ++-
>>  meta/conf/documentation.conf |   2 +-
>>  meta/lib/oeqa/controllers/masterimage.py |   2 +-
>>  meta/lib/oeqa/targetcontrol.py   |   2 +-
>>  meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
>>  scripts/test-remote-image|   2 +-
>>  10 files changed, 175 insertions(+), 81 deletions(-)
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-27 Thread He Zhe

Ping.

On 07/27/2015 10:51 AM, He Zhe wrote:
> Ping.
>
> On 07/23/2015 03:48 PM, He Zhe wrote:
>> Ping.
>>
>> On 07/21/2015 03:23 PM, zhe...@windriver.com wrote:
>>> From: He Zhe 
>>>
>>>  - To support building packaging and installing multi types of kernel
>>>images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>>>as a list.
>>>  - Modify wherever reference KERNEL_IMAGETYPE accordingly.
>>>  - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>>>depending on build machine's, when KEEPUIMAGE is "yes".
>>>  - v2: update with the latest oe-core
>>>
>>> He Zhe (2):
>>>   kernel: Define KERNEL_IMAGETYPE as a list
>>>   kernel: Pass sysroot mkimage to kernel makefile
>>>
>>>  meta/classes/image_types.bbclass |   6 +-
>>>  meta/classes/kernel-fitimage.bbclass |  22 +++---
>>>  meta/classes/kernel-grub.bbclass |  47 
>>>  meta/classes/kernel-uimage.bbclass   |  31 +---
>>>  meta/classes/kernel.bbclass  | 127 
>>> ++-
>>>  meta/conf/documentation.conf |   2 +-
>>>  meta/lib/oeqa/controllers/masterimage.py |   2 +-
>>>  meta/lib/oeqa/targetcontrol.py   |   2 +-
>>>  meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
>>>  scripts/test-remote-image|   2 +-
>>>  10 files changed, 175 insertions(+), 81 deletions(-)
>>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-29 Thread He Zhe

Ping.

Is there any comments on this?

Zhe

On 07/28/2015 11:17 AM, He Zhe wrote:
> Ping.
>
> On 07/27/2015 10:51 AM, He Zhe wrote:
>> Ping.
>>
>> On 07/23/2015 03:48 PM, He Zhe wrote:
>>> Ping.
>>>
>>> On 07/21/2015 03:23 PM, zhe...@windriver.com wrote:
>>>> From: He Zhe 
>>>>
>>>>  - To support building packaging and installing multi types of kernel
>>>>images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>>>>as a list.
>>>>  - Modify wherever reference KERNEL_IMAGETYPE accordingly.
>>>>  - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>>>>depending on build machine's, when KEEPUIMAGE is "yes".
>>>>  - v2: update with the latest oe-core
>>>>
>>>> He Zhe (2):
>>>>   kernel: Define KERNEL_IMAGETYPE as a list
>>>>   kernel: Pass sysroot mkimage to kernel makefile
>>>>
>>>>  meta/classes/image_types.bbclass |   6 +-
>>>>  meta/classes/kernel-fitimage.bbclass |  22 +++---
>>>>  meta/classes/kernel-grub.bbclass |  47 
>>>>  meta/classes/kernel-uimage.bbclass   |  31 +---
>>>>  meta/classes/kernel.bbclass  | 127 
>>>> ++-
>>>>  meta/conf/documentation.conf |   2 +-
>>>>  meta/lib/oeqa/controllers/masterimage.py |   2 +-
>>>>  meta/lib/oeqa/targetcontrol.py   |   2 +-
>>>>  meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
>>>>  scripts/test-remote-image|   2 +-
>>>>  10 files changed, 175 insertions(+), 81 deletions(-)
>>>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-31 Thread He Zhe

Ping.

On 07/29/2015 09:23 PM, Bruce Ashfield wrote:
> On 15-07-29 03:32 AM, He Zhe wrote:
>> Ping.
>>
>> Is there any comments on this?
>
> I'm obviously ok with the patch in its current RFC status. It works
> and I've tested it in my tree (hence why I've been quiet on this
> one).
>
> If it meets the style for merging into core, and that it doesn't
> break other layers we can't see .. I was hoping to hear from others.
>
> Bruce
>
>>
>> Zhe
>>
>> On 07/28/2015 11:17 AM, He Zhe wrote:
>>> Ping.
>>>
>>> On 07/27/2015 10:51 AM, He Zhe wrote:
>>>> Ping.
>>>>
>>>> On 07/23/2015 03:48 PM, He Zhe wrote:
>>>>> Ping.
>>>>>
>>>>> On 07/21/2015 03:23 PM, zhe...@windriver.com wrote:
>>>>>> From: He Zhe 
>>>>>>
>>>>>>   - To support building packaging and installing multi types of kernel
>>>>>> images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>>>>>> as a list.
>>>>>>   - Modify wherever reference KERNEL_IMAGETYPE accordingly.
>>>>>>   - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
>>>>>> depending on build machine's, when KEEPUIMAGE is "yes".
>>>>>>   - v2: update with the latest oe-core
>>>>>>
>>>>>> He Zhe (2):
>>>>>>kernel: Define KERNEL_IMAGETYPE as a list
>>>>>>kernel: Pass sysroot mkimage to kernel makefile
>>>>>>
>>>>>>   meta/classes/image_types.bbclass |   6 +-
>>>>>>   meta/classes/kernel-fitimage.bbclass |  22 +++---
>>>>>>   meta/classes/kernel-grub.bbclass |  47 
>>>>>>   meta/classes/kernel-uimage.bbclass   |  31 +---
>>>>>>   meta/classes/kernel.bbclass  | 127 
>>>>>> ++-
>>>>>>   meta/conf/documentation.conf |   2 +-
>>>>>>   meta/lib/oeqa/controllers/masterimage.py |   2 +-
>>>>>>   meta/lib/oeqa/targetcontrol.py   |   2 +-
>>>>>>   meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
>>>>>>   scripts/test-remote-image|   2 +-
>>>>>>   10 files changed, 175 insertions(+), 81 deletions(-)
>>>>>>
>>
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-31 Thread He Zhe



On 07/31/2015 07:24 PM, Richard Purdie wrote:
> On Wed, 2015-07-22 at 10:29 +0800, He Zhe wrote:
>> On 07/21/2015 10:53 PM, Christopher Larson wrote:
>>> On Tue, Jul 21, 2015 at 12:23 AM, >> <mailto:zhe...@windriver.com>>wrote:
>>>
>>> From: He Zhe mailto:zhe...@windriver.com>>
>>>
>>> To support building packaging and installing multi types of kernel
>>> images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
>>> as a list.
>>> Modify wherever reference KERNEL_IMAGETYPE accordingly.
>>>
>>> Fixes [YOCTO #6945].
>>>
>>> Signed-off-by: He Zhe >> <mailto:zhe...@windriver.com>>
>>>
>>>
>>> Question, why not add KERNEL_IMAGETYPES, and make KERNEL_IMAGETYPE equal to 
>>> your new KERNEL_IMAGETYPE_0?
>> Adding a new KERNEL_IMAGETYPES will also work. But it should be better
>> not to change the name of KERNEL_IMAGETYPE, so that those who have
>> used it don't have to change their code.
>>
>> Thank you for reviewing.
> I have to agree with Chris here, keeping KERNEL_IMAGETYPE as used today
> and equivalent to KERNEL_IMAGETYPE_0 and adding KERNEL_IMAGETYPES does
> seem like a cleaner way to implement this.

But it might mean we are going to check both KERNEL_IMAGETYPE and 
KERNEL_IMAGETYPES
to generate final image type list. Is that OK?

Thanks,
Zhe

> Cheers,
>
> Richard
>
>
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 0/1] Yocto Bug #6945

2015-08-05 Thread He Zhe

Ping.

On 08/04/2015 05:17 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
>  - Add KERNEL_IMAGETYPES to support building packaging and installing
> multi types of kernel images, such as zImage uImage, at one time.
>  - KERNEL_IMAGETYPE works as it did.
>  - v2: Update with the latest oe-core
>  - v3: Add KERNEL_IMAGETYPES, leave KERNEL_IMAGETYPE as is.
>
> Thank Richard for his great suggestion.
>
> He Zhe (1):
>   kernel: Add KERNEL_IMAGETYPES to build multi types of kernel at one
> time
>
>  meta/classes/kernel-fitimage.bbclass|  21 +++---
>  meta/classes/kernel-grub.bbclass|  46 
>  meta/classes/kernel-uimage.bbclass  |  22 +++---
>  meta/classes/kernel.bbclass | 128 
> +++-
>  meta/conf/documentation.conf|   1 +
>  meta/recipes-kernel/linux/linux-dtb.inc |  15 ++--
>  6 files changed, 159 insertions(+), 74 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] kernel: Correct mishandling of linux.bin for building uImage

2015-08-13 Thread He Zhe

Ping.

On 08/11/2015 04:22 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>
>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
> 13:58:02 -0700)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/kernel-uboot
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/kernel-uboot
>
> for you to fetch changes up to 925eb33167a5510d9d2ec76b0d3e1c2f3f109008:
>
>   kernel: Correct mishandling of linux.bin for building uImage (2015-08-11 
> 03:37:27 -0400)
>
> --------
> He Zhe (1):
>   kernel: Correct mishandling of linux.bin for building uImage
>
>  meta/classes/kernel-uboot.bbclass | 1 -
>  1 file changed, 1 deletion(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb

2015-08-13 Thread He Zhe

Ping.

On 08/11/2015 05:08 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>
>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
> 13:58:02 -0700)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/kernel_devicetree
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zhe/kernel_devicetree
>
> for you to fetch changes up to 648173de6f77371c4e0b803af12b23cd514b2d9f:
>
>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb 
> (2015-08-11 04:58:28 -0400)
>
> --------
> He Zhe (1):
>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
>
>  meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/1] Yocto Bug #6945

2015-08-17 Thread He Zhe

Ping.

On 08/10/2015 08:46 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
>  - Add KERNEL_IMAGETYPES to support building packaging and installing
> multi types of kernel images, such as zImage uImage, at one time.
>  - KERNEL_IMAGETYPE works as it did.
>  - v2: Update with the latest oe-core
>  - v3: Add KERNEL_IMAGETYPES, leave KERNEL_IMAGETYPE as is
>  - v4: Turn package name to lower case to meet opkg's requrement
>Modify "if test" in kernel-fitimage.bbclass and kernel-uimage.bbclass
>
>
> He Zhe (1):
>   kernel: Add KERNEL_IMAGETYPES to build multi types of kernel at one
> time
>
>  meta/classes/kernel-fitimage.bbclass|  21 +++---
>  meta/classes/kernel-grub.bbclass|  46 +++
>  meta/classes/kernel-uimage.bbclass  |  22 +++---
>  meta/classes/kernel.bbclass | 130 
> +++-
>  meta/conf/documentation.conf|   1 +
>  meta/recipes-kernel/linux/linux-dtb.inc |  81 
>  6 files changed, 199 insertions(+), 102 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] kernel: Correct mishandling of linux.bin for building uImage

2015-08-23 Thread He Zhe

Ping.

On 08/14/2015 10:50 AM, He Zhe wrote:
> Ping.
>
> On 08/11/2015 04:22 PM, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>>
>>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
>> 13:58:02 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.yoctoproject.org/poky-contrib zhe/kernel-uboot
>>   
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/kernel-uboot
>>
>> for you to fetch changes up to 925eb33167a5510d9d2ec76b0d3e1c2f3f109008:
>>
>>   kernel: Correct mishandling of linux.bin for building uImage (2015-08-11 
>> 03:37:27 -0400)
>>
>> 
>> He Zhe (1):
>>   kernel: Correct mishandling of linux.bin for building uImage
>>
>>  meta/classes/kernel-uboot.bbclass | 1 -
>>  1 file changed, 1 deletion(-)
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb

2015-08-23 Thread He Zhe

Ping.

On 08/14/2015 10:50 AM, He Zhe wrote:
> Ping.
>
> On 08/11/2015 05:08 PM, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>>
>>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
>> 13:58:02 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.yoctoproject.org/poky-contrib zhe/kernel_devicetree
>>   
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zhe/kernel_devicetree
>>
>> for you to fetch changes up to 648173de6f77371c4e0b803af12b23cd514b2d9f:
>>
>>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb 
>> (2015-08-11 04:58:28 -0400)
>>
>> 
>> He Zhe (1):
>>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
>>
>>  meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] kernel: Correct mishandling of linux.bin for building uImage

2015-09-01 Thread He Zhe

Ping.

On 08/24/2015 11:24 AM, He Zhe wrote:
> Ping.
>
> On 08/14/2015 10:50 AM, He Zhe wrote:
>> Ping.
>>
>> On 08/11/2015 04:22 PM, zhe...@windriver.com wrote:
>>> From: He Zhe 
>>>
>>> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>>>
>>>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
>>> 13:58:02 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.yoctoproject.org/poky-contrib zhe/kernel-uboot
>>>   
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/kernel-uboot
>>>
>>> for you to fetch changes up to 925eb33167a5510d9d2ec76b0d3e1c2f3f109008:
>>>
>>>   kernel: Correct mishandling of linux.bin for building uImage (2015-08-11 
>>> 03:37:27 -0400)
>>>
>>> 
>>> He Zhe (1):
>>>   kernel: Correct mishandling of linux.bin for building uImage
>>>
>>>  meta/classes/kernel-uboot.bbclass | 1 -
>>>  1 file changed, 1 deletion(-)
>>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb

2015-09-01 Thread He Zhe

Ping.

On 08/24/2015 11:24 AM, He Zhe wrote:
> Ping.
>
> On 08/14/2015 10:50 AM, He Zhe wrote:
>> Ping.
>>
>> On 08/11/2015 05:08 PM, zhe...@windriver.com wrote:
>>> From: He Zhe 
>>>
>>> The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
>>>
>>>   bitbake: toaster: reduced amount of instance attributes (2015-08-10 
>>> 13:58:02 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.yoctoproject.org/poky-contrib zhe/kernel_devicetree
>>>   
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zhe/kernel_devicetree
>>>
>>> for you to fetch changes up to 648173de6f77371c4e0b803af12b23cd514b2d9f:
>>>
>>>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb 
>>> (2015-08-11 04:58:28 -0400)
>>>
>>> 
>>> He Zhe (1):
>>>   meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
>>>
>>>  meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-17 Thread He Zhe

From: Zhe He 

 - To support building packaging and installing multi types of kernel
   images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
   as a list.
 - Modify wherever reference KERNEL_IMAGETYPE accordingly.

Signed-off-by: Zhe He 
---
 meta/classes/image_types.bbclass |   6 +-
 meta/classes/kernel-fitimage.bbclass |  22 +++---
 meta/classes/kernel-grub.bbclass |  47 
 meta/classes/kernel-uimage.bbclass   |  31 +---
 meta/classes/kernel.bbclass  | 125 ++-
 meta/conf/documentation.conf |   2 +-
 meta/lib/oeqa/controllers/masterimage.py |   2 +-
 meta/lib/oeqa/targetcontrol.py   |   2 +-
 meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
 scripts/test-remote-image|   2 +-
 10 files changed, 174 insertions(+), 80 deletions(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 588a474..b04470f 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -4,6 +4,10 @@
 # set this value to 2048 (2MiB alignment).
 IMAGE_ROOTFS_ALIGNMENT ?= "1"
 
+python __anonymous () {
+   d.setVar('KERNEL_IMAGETYPE_0', d.getVar('KERNEL_IMAGETYPE', 
True).strip().split(' ')[0])
+}
+
 def imagetypes_getdepends(d):
 def adddep(depstr, deps):
 for i in (depstr or "").split():
@@ -86,7 +90,7 @@ IMAGE_CMD_cpio () {
fi
 }
 
-ELF_KERNEL ?= "${STAGING_DIR_HOST}/usr/src/kernel/${KERNEL_IMAGETYPE}"
+ELF_KERNEL ?= "${STAGING_DIR_HOST}/usr/src/kernel/${KERNEL_IMAGETYPE_0}"
 ELF_APPEND ?= "ramdisk_size=32768 root=/dev/ram0 rw console="
 
 IMAGE_CMD_elf () {
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2a56a54..7d097b4 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ""
+if 'fitImage' in kerneltype.strip().split(' '):
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,11 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+list = typeformake.strip().split(' ')
+if 'fitImage' in list:
+list.remove('fitImage')
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', ' '.join(list))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -154,7 +158,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if test "x${KERNEL_IMAGETYPE}" != "x${KERNEL_IMAGETYPE//fitImage/}" ; 
then
kernelcount=1
dtbcount=""
rm -f fit-image.its
@@ -217,14 +221,14 @@ addtask assemble_fitimage before do_install after 
do_compile
 
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if test "x${KERNEL_IMAGETYPE}" != "x${KERNEL_IMAGETYPE//fitImage/}" ; 
then
cd ${B}
echo "Copying fit-image.its source file..."
-   
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+   its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
-   
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+   
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin 
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass b/meta/classes/kernel-grub.bbclass
index a63f482..ceb0fa1 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append () {
+python __anonymous () {
+import re
+
+preinst = '''
# Parsing confliction
[ -f "$D/boot/grub/menu.list" ] && grubcfg="$D/boot/grub/menu.list"
[ -f "$D/boot/grub/grub.cfg" ] && grubcfg="$D/boot/grub/grub.cfg"
if [ -n "$grubcfg" ]; the

[OE-core] [PATCH 2/2] kernel: Pass sysroot mkimage to kernel makefile

2015-07-17 Thread He Zhe

Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
depending on build machine's, if KEEPUIMAGE is "yes".

Signed-off-by: He Zhe 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 86ed28f..1d7fa48 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -141,7 +141,7 @@ UBOOT_ENTRYPOINT ?= "20008000"
 UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
 
 # Some Linux kernel configurations need additional parameters on the command 
line
-KERNEL_EXTRA_ARGS ?= ""
+KERNEL_EXTRA_ARGS ?= "NATIVE_MKIMAGE=${STAGING_BINDIR_NATIVE}/mkimage"
 
 # For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE.
 # We don't want to override kernel Makefile variables from the environment
-- 
2.3.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] Yocto Bug #6945

2015-07-17 Thread He Zhe

From: Zhe He 

 - To support building packaging and installing multi types of kernel
   images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
   as a list.
 - Modify wherever reference KERNEL_IMAGETYPE accordingly.

He Zhe (2):
  kernel: Define KERNEL_IMAGETYPE as a list
  kernel: Pass sysroot mkimage to kernel makefile

 meta/classes/image_types.bbclass |   6 +-
 meta/classes/kernel-fitimage.bbclass |  22 +++---
 meta/classes/kernel-grub.bbclass |  47 
 meta/classes/kernel-uimage.bbclass   |  31 +---
 meta/classes/kernel.bbclass  | 127 ++-
 meta/conf/documentation.conf |   2 +-
 meta/lib/oeqa/controllers/masterimage.py |   2 +-
 meta/lib/oeqa/targetcontrol.py   |   2 +-
 meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
 scripts/test-remote-image|   2 +-
 10 files changed, 175 insertions(+), 81 deletions(-)

Cc: Bruce Ashfield 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-21 Thread He Zhe

On 07/21/2015 10:53 PM, Christopher Larson wrote:
>
> On Tue, Jul 21, 2015 at 12:23 AM,  <mailto:zhe...@windriver.com>>wrote:
>
> From: He Zhe mailto:zhe...@windriver.com>>
>
> To support building packaging and installing multi types of kernel
> images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
> as a list.
> Modify wherever reference KERNEL_IMAGETYPE accordingly.
>
>     Fixes [YOCTO #6945].
>
> Signed-off-by: He Zhe mailto:zhe...@windriver.com>>
>
>
> Question, why not add KERNEL_IMAGETYPES, and make KERNEL_IMAGETYPE equal to 
> your new KERNEL_IMAGETYPE_0?

Adding a new KERNEL_IMAGETYPES will also work. But it should be better not to 
change the name of KERNEL_IMAGETYPE, so that those who have used it don't have 
to change their code.

Thank you for reviewing.

Zhe

> -- 
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-dummy: Add package kernel

2019-10-31 Thread He Zhe




On 10/31/19 6:57 PM, Bruce Ashfield wrote:
> On Thu, Oct 31, 2019 at 6:20 AM  wrote:
>> From: He Zhe 
>>
>> Some package like packagegroup-core-boot may ask for package kernel. Let
>> linux-dummy rprovide package kernel to fix the following build failure.
>>
>> ERROR: Nothing RPROVIDES 'kernel' (but
>> .../meta/recipes-core/packagegroups/packagegroup-core-boot.bb RDEPENDS on or
>> otherwise requires it)
> Can you expand on what the higher level use case is that something is
> using packagegroup-core-boot (or whatever), but also linux-dummy ?
>
> It seems like this is going to hide misconfigurations .. since you may
> want something bootable, but yet are not properly configured.
>
> If there's part of that packagroup you need, why not split it up,
> rather than masking the symptom seen here ?

It's the "efi" in MACHINE_FEATURES who asks for "kernel".
https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-boot.bb#n31

I thought the user would take care of the kernel himself, so simply added it to
linux-dummy. I'm not quite sure what you mean by "split it up".

Regards,
Zhe

>
> Bruce
>
>> Signed-off-by: He Zhe 
>> ---
>>  meta/recipes-kernel/linux/linux-dummy.bb | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux/linux-dummy.bb 
>> b/meta/recipes-kernel/linux/linux-dummy.bb
>> index 62cf6f5ea6..20d7ed815d 100644
>> --- a/meta/recipes-kernel/linux/linux-dummy.bb
>> +++ b/meta/recipes-kernel/linux/linux-dummy.bb
>> @@ -8,19 +8,22 @@ LICENSE = "GPLv2"
>>  LIC_FILES_CHKSUM = 
>> "file://${WORKDIR}/COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
>>
>>  PROVIDES += "virtual/kernel"
>> +RPROVIDES_${PN} += "kernel lib32-kernel"
>>
>>  PACKAGES_DYNAMIC += "^kernel-module-.*"
>>  PACKAGES_DYNAMIC += "^kernel-image-.*"
>>  PACKAGES_DYNAMIC += "^kernel-firmware-.*"
>>
>> -PACKAGES += "kernel-modules kernel-vmlinux"
>> +PACKAGES += "kernel-modules kernel-vmlinux kernel"
>>  FILES_kernel-modules = ""
>>  ALLOW_EMPTY_kernel-modules = "1"
>>  DESCRIPTION_kernel-modules = "Kernel modules meta package"
>>  FILES_kernel-vmlinux = ""
>>  ALLOW_EMPTY_kernel-vmlinux = "1"
>>  DESCRIPTION_kernel-vmlinux = "Kernel vmlinux meta package"
>> -
>> +FILES_kernel = ""
>> +ALLOW_EMPTY_kernel = "1"
>> +DESCRIPTION_kernel = "Kernel meta package"
>>
>>  INHIBIT_DEFAULT_DEPS = "1"
>>
>> --
>> 2.17.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-dummy: Add package kernel

2019-11-05 Thread He Zhe




On 11/4/19 9:32 PM, Ross Burton wrote:
> On 01/11/2019 02:01, He Zhe wrote:
>> It's the "efi" in MACHINE_FEATURES who asks for "kernel".
>> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-boot.bb#n31
>
> I'd just rip out 'kernel' from that as that doesn't look right to me.

Not sure if the following patch is still the case.
http://lists.openembedded.org/pipermail/openembedded-core/2018-February/266287.html

Thanks,
Zhe

>
> Ross
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 0/2] Yocto Bug #6945

2016-04-05 Thread He Zhe



On 03/23/2016 02:29 AM, Bruce Ashfield wrote:
>
>
> On Mon, Mar 21, 2016 at 11:37 PM, Bruce Ashfield  <mailto:bruce.ashfi...@gmail.com>>wrote:
>
>
>
> On Mon, Mar 21, 2016 at 10:31 PM, He Zhe  <mailto:zhe...@windriver.com>>wrote:
>
> Ping.
>
>
> This slipped through my filters. Sorry about that.
>
> We are too late for the 2.1 release at this point, but I'll review the 
> changes again in the
> morning and send any comments that I may have.
>
>
> I reviewed this version, and it looks fine to me.
>

Thank you Bruce. And which version do we expect this to be merged into? 2.1.1 
or 2.2 M1?

Zhe

> Bruce
>  
>
>
> Cheers,
>
> Bruce
>  
>
> Thanks,
> Zhe
>
> On 03/11/2016 11:32 AM, He Zhe wrote:
> > Any more comments?
> >
> > Thanks,
>     > Zhe
> >
> > On 02/24/2016 08:20 PM, zhe...@windriver.com 
> <mailto:zhe...@windriver.com>wrote:
> >> From: He Zhe mailto:zhe...@windriver.com>>
> >>
> >> v1 to v2:
> >>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
> >>  - Update related doc files
> >>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
> >>  - Link built vmlinuz to boot directory for reference
> >>
> >> v2 to v3:
> >>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in 
> order that users can still use the old variables.
> >>  - Run oe_rummake in a loop for every types so that we can add 
> different configurations to them easily in the future.
> >>  - Warn, intead of die, users if one of the types are over the 
> size limit.
> >>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
> >>  - Remove the doc parts. They will be submitted yocto-docs later.
> >>  - Change some grep usage to make it more clear.
> >>  - Correct a typo.
> >>
> >> The following changes since commit 
> 23056103c949b498c23b47579e8dd57ce78e6ed9:
> >>
> >>   uclibc: Do not use immediate expansion operator (2016-02-22 
> 20:42:48 +)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.yoctoproject.org/poky-contrib 
> <http://git.yoctoproject.org/poky-contrib>zhe/yocto-bug-6945
>     >>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/yocto-bug-6945
> >>
> >> for you to fetch changes up to 
> dc52a1efbb8248ea274a1cd0cca5734290b3025f:
> >>
> >>   kernel: Make symbol link to vmlinuz in boot directory 
> (2016-02-24 07:08:16 -0500)
> >>
> >> 
> >> He Zhe (2):
> >>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at 
> one time
> >>   kernel: Make symbol link to vmlinuz in boot directory
> >>
> >>  meta/classes/kernel-fitimage.bbclass  |  20 ---
> >>  meta/classes/kernel-grub.bbclass  |  44 
> +---
> >>  meta/classes/kernel-uimage.bbclass    |  22 
> >>  meta/classes/kernel.bbclass   | 187 
> ---
> >>  meta/conf/documentation.conf  |   3 ++-
> >>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
> ++--
> >>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
> >>  7 files changed, 218 insertions(+), 109 deletions(-)
> >>
> >> He Zhe (2):
> >>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one 
> time
> >>   kernel: Make symbol link to vmlinuz in boot directory
> >>
> >>  meta/classes/kernel-fitimage.bbclass  |  20 ++--
> >>  meta/classes/kernel-grub.bbclass  |  44 ---
> >>  meta/classes/kernel-uimage.bbclass|  22 ++--
> >>  meta/classes/kernel.bbclass   | 187 
> +-
> >>  meta/conf/documentation.conf  |   3 +-
>

Re: [OE-core] [PATCH v4 0/2] Yocto Bug #6945

2016-05-19 Thread He Zhe

Ping.

On 05/12/2016 05:48 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> This has been reviewed several rounds and no more comments are provided so 
> far.
> Here are the brief history. More details can be found in the previous threads.
>
> v1 to v2:
>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
>  - Update related doc files
>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
>  - Link built vmlinuz to boot directory for reference
>
> v2 to v3:
>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order that 
> users can still use the old variables.
>  - Run oe_rummake in a loop for every types so that we can add different 
> configurations to them easily in the future.
>  - Warn, intead of die, users if one of the types are over the size limit.
>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
>  - Remove the doc parts. They will be submitted yocto-docs later.
>  - Change some grep usage to make it more clear.
>  - Correct a typo.
>
> v3 to v4:
>  - Adjust according to the latest code context
>
> The following changes since commit 7ca60ec8bff7656b4e52f5a4d238913e851da089:
>
>   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:48:06 +0100)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/yocto-bug-6945
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=zhe%2Fyocto-bug-6945
>
> for you to fetch changes up to 1f37fe5af2c41d0a4e1aa5543466a48d3ae41ddc:
>
>   kernel: Make symbol link to vmlinuz in boot directory (2016-05-11 04:05:08 
> -0400)
>
> 
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ---
>  meta/classes/kernel-grub.bbclass  |  44 
> +---
>  meta/classes/kernel-uimage.bbclass|  22 
>  meta/classes/kernel.bbclass   | 187 
> ---
>  meta/conf/documentation.conf  |   3 ++-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
> ++--
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 218 insertions(+), 109 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/2] Yocto Bug #6945

2016-05-26 Thread He Zhe



On 05/25/2016 08:12 PM, Bruce Ashfield wrote:
>
>
> On Wed, May 25, 2016 at 4:47 AM,  <mailto:zhe...@windriver.com>> wrote:
>
> From: He Zhe mailto:zhe...@windriver.com>>
>
> This has been reviewed several rounds and no more comments are provided 
> so far.
> Here is the brief history. More details can be found in the previous 
> threads.
> Hopefully this can be merged in v2.2 m1.
>
> v1 to v2:
>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
>  - Update related doc files
>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
>  - Link built vmlinuz to boot directory for reference
>
> v2 to v3:
>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order 
> that users can still use the old variables.
>  - Run oe_rummake in a loop for every types so that we can add different 
> configurations to them easily in the future.
>  - Warn, intead of die, users if one of the types are over the size limit.
>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
>  - Remove the doc parts. They will be submitted yocto-docs later.
>  - Change some grep usage to make it more clear.
>  - Correct a typo.
>
> v3 to v4:
>  - Adjust according to the latest code context
>
>
>
> v4 looks ok to me.
>
> There was another series posted: [kernel-multi: stage and package multiple 
> kernels], did
> you have a look at that one? Do these two series work properly together ?
>

These two can not work properly together for the moment. My series build multi 
types of
kernels. "kernel-multi" aims at building another version of kernel by 
optionally extending
kernel.bbclass to kernel-multi.bbclass.

If we want both of the two features, "kernel-multi" might need to be changed 
according to
mine, since it inherits kernel.bbclass and overrides some variables before 
doing its own job.
e.g. "kernel-multi" uses KERNEL_IMAGETYPE as the only kernel image type, 
whereas my
series use KERNEL_IMAGETYPE plus KERNEL_IMAGETYPES as bug #6945 wants.

Thanks,
Zhe

> Bruce
>
>
> The following changes since commit 
> c7e614c438706fb3ed7520b4990ebb3973366942:
>
>   useradd: Fix infinite build loop (2016-05-23 10:33:45 +0100)
>
> are available in the git repository at:
>
>   git.yoctoproject.org/poky-contrib 
> <http://git.yoctoproject.org/poky-contrib> zhe/yocto-bug-6945
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=zhe%2Fyocto-bug-6945
>
> for you to fetch changes up to 4cd0e844d4153f2eb2cc54fafbfd161341ef4539:
>
>   kernel: Make symbol link to vmlinuz in boot directory (2016-05-24 
> 22:57:35 -0400)
>
> 
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one 
> time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ---
>  meta/classes/kernel-grub.bbclass  |  44 
> +---
>  meta/classes/kernel-uimage.bbclass|  10 +---
>  meta/classes/kernel.bbclass   | 187 
> ---
>  meta/conf/documentation.conf  |   3 ++-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
> ++--
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 212 insertions(+), 103 deletions(-)
>
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ++--
>  meta/classes/kernel-grub.bbclass  |  44 ---
>  meta/classes/kernel-uimage.bbclass|  10 +-
>  meta/classes/kernel.bbclass   | 187 
> +-
>  meta/conf/documentation.conf  |   3 +-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 +---
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 212 insertions(+), 103 deletions(-)
>
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org 
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
> its end"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/2] Yocto Bug #6945

2016-05-29 Thread He Zhe

Hi Richard,

Do we have plan to try this in v2.2 m1 or some milestone later?

Thanks,
Zhe

On 05/25/2016 04:47 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> This has been reviewed several rounds and no more comments are provided so 
> far.
> Here is the brief history. More details can be found in the previous threads.
> Hopefully this can be merged in v2.2 m1.
>
> v1 to v2: 
>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
>  - Update related doc files
>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
>  - Link built vmlinuz to boot directory for reference
>
> v2 to v3: 
>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order that 
> users can still use the old variables.
>  - Run oe_rummake in a loop for every types so that we can add different 
> configurations to them easily in the future.
>  - Warn, intead of die, users if one of the types are over the size limit.
>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2. 
>  - Remove the doc parts. They will be submitted yocto-docs later.
>  - Change some grep usage to make it more clear.
>  - Correct a typo.
>
> v3 to v4: 
>  - Adjust according to the latest code context
>
> The following changes since commit c7e614c438706fb3ed7520b4990ebb3973366942:
>
>   useradd: Fix infinite build loop (2016-05-23 10:33:45 +0100)
>
> are available in the git repository at:
>
>   git.yoctoproject.org/poky-contrib zhe/yocto-bug-6945
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=zhe%2Fyocto-bug-6945
>
> for you to fetch changes up to 4cd0e844d4153f2eb2cc54fafbfd161341ef4539:
>
>   kernel: Make symbol link to vmlinuz in boot directory (2016-05-24 22:57:35 
> -0400)
>
> 
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ---
>  meta/classes/kernel-grub.bbclass  |  44 
> +---
>  meta/classes/kernel-uimage.bbclass|  10 +---
>  meta/classes/kernel.bbclass   | 187 
> ---
>  meta/conf/documentation.conf  |   3 ++-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
> ++--
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 212 insertions(+), 103 deletions(-)
>
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ++--
>  meta/classes/kernel-grub.bbclass  |  44 ---
>  meta/classes/kernel-uimage.bbclass|  10 +-
>  meta/classes/kernel.bbclass   | 187 
> +-
>  meta/conf/documentation.conf  |   3 +-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 +---
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 212 insertions(+), 103 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] lttng-modules: upgrade 2.10.5 -> 2.10.6

2018-06-20 Thread He Zhe

Signed-off-by: He Zhe 
---
 .../lttng/{lttng-modules_2.10.5.bb => lttng-modules_2.10.6.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-modules_2.10.5.bb => 
lttng-modules_2.10.6.bb} (90%)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.5.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.10.6.bb
similarity index 90%
rename from meta/recipes-kernel/lttng/lttng-modules_2.10.5.bb
rename to meta/recipes-kernel/lttng/lttng-modules_2.10.6.bb
index 370b78aae14..6146966894d 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.10.5.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.6.bb
@@ -16,8 +16,8 @@ SRC_URI = 
"https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
 "
 
-SRC_URI[md5sum] = "4aaabaafd15d9455c83972e26ccfbca7"
-SRC_URI[sha256sum] = 
"b8dbbbee45a673c381f51b99c555e36655c3c2c7a5477aab927591cc7f003a1f"
+SRC_URI[md5sum] = "8110099f4615fc89a74ffe9189b56cfc"
+SRC_URI[sha256sum] = 
"04a080c81743eb29d181bac29ceb0c15819a2f4210793f2cc9958d885435029f"
 
 export INSTALL_MOD_DIR="kernel/lttng-modules"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cryptodev: Fix build errors with v4.17+

2018-06-21 Thread He Zhe

Backport from upstream to update internal syscall function usage.
https://github.com/cryptodev-linux/cryptodev-linux
f60aa08c63fc02780554a0a12180a478ca27d49f

Signed-off-by: He Zhe 
---
 .../cryptodev/cryptodev-module_1.9.bb  |  1 +
 .../0001-ioctl.c-Fix-build-with-linux-4.17.patch   | 43 ++
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.17.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
index ed6d0ecae97..6052650c955 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
@@ -10,6 +10,7 @@ DEPENDS += "cryptodev-linux"
 SRC_URI += " \
 file://0001-Disable-installing-header-file-provided-by-another-p.patch \
 file://0001-ioctl.c-Fix-build-with-linux-4.13.patch \
+file://0001-ioctl.c-Fix-build-with-linux-4.17.patch \
 "
 
 EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.17.patch
 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.17.patch
new file mode 100644
index 000..5881d1c4eec
--- /dev/null
+++ 
b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.17.patch
@@ -0,0 +1,43 @@
+From f60aa08c63fc02780554a0a12180a478ca27d49f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Horia=20Geant=C4=83?= 
+Date: Wed, 23 May 2018 18:43:39 +0300
+Subject: [PATCH] ioctl.c: Fix build with linux 4.17
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Since kernel 4.17-rc1, sys_* syscalls can no longer be called directly:
+819671ff849b ("syscalls: define and explain goal to not call syscalls in the 
kernel")
+
+Since cryptodev uses sys_close() - and this has been removed in commit:
+2ca2a09d6215 ("fs: add ksys_close() wrapper; remove in-kernel calls to 
sys_close()")
+cryptodev has to be updated to use the ksys_close() wrapper.
+
+Signed-off-by: Horia Geantă 
+
+Upstream-Status: Backport
+
+Signed-off-by: He Zhe 
+---
+ ioctl.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/ioctl.c b/ioctl.c
+index d831b0c..2571034 100644
+--- a/ioctl.c
 b/ioctl.c
+@@ -828,7 +828,11 @@ cryptodev_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg_)
+   fd = clonefd(filp);
+   ret = put_user(fd, p);
+   if (unlikely(ret)) {
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 17, 0))
+   sys_close(fd);
++#else
++  ksys_close(fd);
++#endif
+   return ret;
+   }
+   return ret;
+-- 
+2.7.4
+
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] qemu: Fix pci-assign

2016-12-20 Thread He Zhe

Ping.

Zhe


On 11/29/2016 05:56 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> Fix iommu pci device assignment failure.
>
> "qemu-system-x86_64: -device pci-assign,host=02:00.0: No IOMMU found.
> Unable to assign device "(null)""
>
> Signed-off-by: He Zhe 
> ---
>  ...sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch | 71 
> ++
>  meta/recipes-devtools/qemu/qemu_2.7.0.bb   |  1 +
>  2 files changed, 72 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
>
> diff --git 
> a/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
>  
> b/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
> new file mode 100644
> index 000..03472dd
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
> @@ -0,0 +1,71 @@
> +From 6baa545df93253fced4fc0d52b14b98447e00473 Mon Sep 17 00:00:00 2001
> +From: Peter Xu 
> +Date: Mon, 28 Nov 2016 15:02:44 +0800
> +Subject: [PATCH] pci-assign: sync MSI/MSI-X cap and table with PCIDevice
> +
> +Since commit e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn"),
> +kvm_irqchip_add_msi_route() starts to use pci_get_msi_message() to fetch
> +MSI info. This requires that we setup MSI related fields in PCIDevice.
> +For most devices, that won't be a problem, as long as we are using
> +general interfaces like msi_init()/msix_init().
> +
> +However, for pci-assign devices, MSI/MSI-X is treated differently - PCI
> +assign devices are maintaining its own MSI table and cap information in
> +AssignedDevice struct. however that's not synced up with PCIDevice's
> +fields. That will leads to pci_get_msi_message() failed to find correct
> +MSI capability, even with an NULL msix_table.
> +
> +A quick fix is to sync up the two places: both the capability bits and
> +table address for MSI/MSI-X.
> +
> +Upstream-Status: Backport 
> [https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg04649.html]
> +
> +Reported-by: Changlimin 
> +Tested-by: Changlimin 
> +Cc: address@hidden
> +Fixes: e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn")
> +Signed-off-by: Peter Xu 
> +Signed-off-by: He Zhe 
> +---
> + hw/i386/kvm/pci-assign.c | 4 
> + 1 file changed, 4 insertions(+)
> +
> +diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
> +index 8238fbc..87dcbdd 100644
> +--- a/hw/i386/kvm/pci-assign.c
>  b/hw/i386/kvm/pci-assign.c
> +@@ -1251,6 +1251,7 @@ static int assigned_device_pci_cap_init(PCIDevice 
> *pci_dev, Error **errp)
> + error_propagate(errp, local_err);
> + return -ENOTSUP;
> + }
> ++dev->dev.cap_present |= QEMU_PCI_CAP_MSI;
> + dev->cap.available |= ASSIGNED_DEVICE_CAP_MSI;
> + /* Only 32-bit/no-mask currently supported */
> + ret = pci_add_capability2(pci_dev, PCI_CAP_ID_MSI, pos, 10,
> +@@ -1285,6 +1286,7 @@ static int assigned_device_pci_cap_init(PCIDevice 
> *pci_dev, Error **errp)
> + error_propagate(errp, local_err);
> + return -ENOTSUP;
> + }
> ++dev->dev.cap_present |= QEMU_PCI_CAP_MSIX;
> + dev->cap.available |= ASSIGNED_DEVICE_CAP_MSIX;
> + ret = pci_add_capability2(pci_dev, PCI_CAP_ID_MSIX, pos, 12,
> +   &local_err);
> +@@ -1648,6 +1650,7 @@ static void 
> assigned_dev_register_msix_mmio(AssignedDevice *dev, Error **errp)
> + dev->msix_table = NULL;
> + return;
> + }
> ++dev->dev.msix_table = (uint8_t *)dev->msix_table;
> + 
> + assigned_dev_msix_reset(dev);
> + 
> +@@ -1665,6 +1668,7 @@ static void 
> assigned_dev_unregister_msix_mmio(AssignedDevice *dev)
> + error_report("error unmapping msix_table! %s", strerror(errno));
> + }
> + dev->msix_table = NULL;
> ++dev->dev.msix_table = NULL;
> + }
> + 
> + static const VMStateDescription vmstate_assigned_device = {
> +-- 
> +2.8.3
> +
> diff --git a/meta/recipes-devtools/qemu/qemu_2.7.0.bb 
> b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> index cef181d..9da5134 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> @@ -13,6 +13,7 @@ SRC_URI += 
> "file://configure-fix-Darwin-target-detection.patch \
>  file://0002-fix-CVE-2016-7423.patch \
>  file://0003-fix-CVE-2016-7908.patch \
>  file://0004-fix-CVE-2016-7909.patch \
> +
> file://0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch \
>  "
>  
>  SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/1] kexec-tools: Upgrade to 2.0.14

2016-12-28 Thread He Zhe



On 12/28/2016 08:15 PM, Alexander Kanavin wrote:
> On 12/27/2016 08:43 AM, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> Remove kexec-aarch64.patch since it has been merged upstream
>> Remove kexec-x32.patch since it has been reverted upstream
>> Backport patches for kdump arm64 from:
>> https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
>>
>> v1 to v2: Remove redundant tarball link in SRC_URI
>
> None of my comments are addressed in this new version of the patch. 
> Specifically:
>
> > Remove kexec-aarch64.patch since it has been merged upstream
> > Remove kexec-x32.patch since it has been reverted upstream
>
> You should also remove the actual files, not just drop them from the recipe.
>
> > Backport patches for kdump arm64 from:
> > https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
>
> If the patches are coming from a different repository, they are not a 
> backport. Change the upstream-status to 'pending' please, or 'submitted 
> (link)' if they have been submitted upstream.
>
> >  meta/recipes-kernel/kexec/kexec-tools_2.0.12.bb|  37 
> >  meta/recipes-kernel/kexec/kexec-tools_2.0.14.bb|  44 +
>
> Please use git's rename detection when submitting patches, so we can see what 
> is the difference between the two files.
>

Thank you for your careful review. Sorry for missing your comments for v1 since 
I just filter mails specifically sent to me...
I'll send v3 soon.

Thanks,
Zhe

>
> Alex
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] scripts/runqemu: qemumips support up to 2GiB RAM

2018-07-03 Thread He Zhe

OE uses qemumips to simulate a Malta board by default.

As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b

The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
...

But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski 
Date:   Wed Nov 23 14:43:49 2016 +0100

MIPS: fix mem=X@Y commandline processing
...

So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.

Signed-off-by: Hongxu Jia 
Signed-off-by: He Zhe 
---
 scripts/runqemu | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index de42d0f323..597e7e9a79 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -668,7 +668,10 @@ class BaseConfig(object):
 logger.info('QB_MEM is not set, use 512M by default')
 self.set('QB_MEM', '-m 512')
 
-self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
+mach = self.get('MACHINE')
+if mach != 'qemumips':
+self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
+
 self.qemu_opt_script += ' %s' % self.get('QB_MEM')
 
 def check_tcpserial(self):
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] scripts/runqemu: fix qemumips64 with 512M RAM caused kernel panic

2018-07-03 Thread He Zhe

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[0.00] Call Trace:
[0.00] [] clear_page+0x0/0x128
[0.00] [] get_page_from_freelist+0xab8/0xc00
[0.00] [] __alloc_pages_nodemask+0xdc/0xf68
[0.00] [] __get_free_pages+0x18/0x70
[0.00] [] setup_zero_pages+0x1c/0xb8
[0.00] [] mem_init+0x54/0xa0
[0.00] [] start_kernel+0x204/0x4d8
[0.00] [] kernel_entry+0x0/0x40
[0.00] Code: 02002025  1000f8d9  8e634d7c <34860f80> cc9e
cc9e0020  cc9e0040  cc9e0060  cc9e0080
[0.00]
[0.00] ---[ end trace  ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
...

Remove `mem=*' to disable user-defined physical RAM map which
let kernel itself caculates memory ranges.

Signed-off-by: Hongxu Jia 
Signed-off-by: He Zhe 
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 597e7e9a79..78f5c8b778 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -669,7 +669,7 @@ class BaseConfig(object):
 self.set('QB_MEM', '-m 512')
 
 mach = self.get('MACHINE')
-if mach != 'qemumips':
+if mach != 'qemumips' and mach != 'qemumips64':
 self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
 
 self.qemu_opt_script += ' %s' % self.get('QB_MEM')
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] lttng-tools: Allow reconnect to relayd

2018-07-04 Thread He Zhe

If relayd is started after connection attempt from consumerd it will
leave the session in disconnected state and causes the following
inconvenience. This is covered by an upstream feature, see
https://bugs.lttng.org/issues/883. Before it's done, this patches
allows users to reconnect to relayd.

root@localhost:~# lttng enable-event --userspace --all
Error: Events: UST create channel failed (channel channel0, session 
trace_session)
root@localhost:~# lttng-relayd -b
Warning: No tracing group detected
root@localhost:~# lttng enable-event --userspace --all
Error: Events: UST create channel failed (channel channel0, session 
trace_session)

Signed-off-by: He Zhe 
---
 ...ow-multiple-attempts-to-connect-to-relayd.patch | 43 ++
 meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb |  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
new file mode 100644
index 000..62a0978592d
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
@@ -0,0 +1,43 @@
+From 70eff899104b86bae02862927c76caaef5de5d3c Mon Sep 17 00:00:00 2001
+From: Mikael Beckius 
+Date: Thu, 7 May 2015 16:14:25 +0200
+Subject: [PATCH] Allow multiple attempts to connect to relayd.
+
+It is unclear why a session needs to be made
+unusable after a failure to connect to relayd
+since a check for a relayd connection is
+always made before a session can be configured.
+
+The behaviour was introduced in:
+d9078d0c000d04d49c599a72c1a725026b636ec0
+
+Signed-off-by: Mikael Beckius 
+[ The context has moved, adjust the hunk accordingly ]
+Signed-off-by: He Zhe 
+Upstream-Status: Pending
+---
+ src/bin/lttng-sessiond/cmd.c |8 
+ 1 file changed, 8 deletions(-)
+
+diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
+index 73b4ce3..36f62ee 100644
+--- a/src/bin/lttng-sessiond/cmd.c
 b/src/bin/lttng-sessiond/cmd.c
+@@ -689,14 +689,6 @@ close_sock:
+   free(rsock);
+ 
+ error:
+-  if (ret != LTTNG_OK) {
+-  /*
+-   * The consumer output for this session should not be used 
anymore
+-   * since the relayd connection failed thus making any tracing 
or/and
+-   * streaming not usable.
+-   */
+-  consumer->enabled = 0;
+-  }
+   return ret;
+ }
+ 
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
index 93626dd4b5f..e4969c30807 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
@@ -30,6 +30,7 @@ PACKAGECONFIG_remove_riscv64 = "lttng-ust"
 SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://x32.patch \
file://run-ptest \
+   file://0001-Allow-multiple-attempts-to-connect-to-relayd.patch \
"
 
 SRC_URI[md5sum] = "051224eb991aee07f8721ff1877d0b96"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] scripts/runqemu: qemumips support up to 2GiB RAM

2018-07-05 Thread He Zhe



On 2018年07月04日 21:29, Khem Raj wrote:
> i think you can squash both patches into one. Additionally we should
> be able to cover mipsel case as well

I started a build with latest poky and only set DEFAULTTUE=mipsel. Is this the 
right way to use little endian?

Then I got the following error and found kernel and kernel modules output are 
all big endian.

ERROR: linux-yocto-4.14.48+gitAUTOINC+94457657b8_6c2433d7c5-r0 do_package_qa: 
QA Issue: Endiannes did not match (1 to 0) on 
/work/qemumips-poky-linux/linux-yocto/4.14.48+gitAUTOINC+94457657b8_6c2433d7c5-r0/packages-split/kernel-module-i2c-dev-4.14.48-yocto-standard/lib/modules/4.14.48-yocto-standard/kernel/drivers/i2c/i2c-dev.ko
 [arch]

Then I tried to build a empty file.
tmp/work/x86_64-linux/gcc-cross-mipsel/8.1.0-r0/recipe-sysroot-native/usr/bin/mipsel-poky-linux/mipsel-poky-linux-gcc
 -c a.c
as: unrecognized option '-EL'

Does it mean there something wrong with little endian toolchain?

Zhe

> On Tue, Jul 3, 2018 at 11:57 PM He Zhe  wrote:
>> OE uses qemumips to simulate a Malta board by default.
>>
>> As upstream qemu introduced:
>> https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
>>
>> The Malta board can support up to 2GiB of RAM which should
>> be able to boot a Linux kernel built with CONFIG_HIGHMEM
>> enabled and passing "-m 2048" to QEMU and appending the
>> following kernel parameters:
>> ...
>> mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
>> ...
>>
>> But the following commit in kernel broke above mem=X@Y setting
>> which added the memory as reserved memory area.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
>> ...
>> commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
>> Author: Marcin Nowakowski 
>> Date:   Wed Nov 23 14:43:49 2016 +0100
>>
>> MIPS: fix mem=X@Y commandline processing
>> ...
>>
>> So remove `mem=*' to disable user-defined physical RAM map
>> which let kernel itself caculates memory ranges.
>>
>> Signed-off-by: Hongxu Jia 
>> Signed-off-by: He Zhe 
>> ---
>>  scripts/runqemu | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/runqemu b/scripts/runqemu
>> index de42d0f323..597e7e9a79 100755
>> --- a/scripts/runqemu
>> +++ b/scripts/runqemu
>> @@ -668,7 +668,10 @@ class BaseConfig(object):
>>  logger.info('QB_MEM is not set, use 512M by default')
>>  self.set('QB_MEM', '-m 512')
>>
>> -self.kernel_cmdline_script += ' mem=%s' % 
>> self.get('QB_MEM').replace('-m','').strip() + 'M'
>> +mach = self.get('MACHINE')
>> +if mach != 'qemumips':
>> +self.kernel_cmdline_script += ' mem=%s' % 
>> self.get('QB_MEM').replace('-m','').strip() + 'M'
>> +
>>  self.qemu_opt_script += ' %s' % self.get('QB_MEM')
>>
>>  def check_tcpserial(self):
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-06 Thread He Zhe

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[0.00] Call Trace:
[0.00] [] clear_page+0x0/0x128
[0.00] [] get_page_from_freelist+0xab8/0xc00
[0.00] [] __alloc_pages_nodemask+0xdc/0xf68
[0.00] [] __get_free_pages+0x18/0x70
[0.00] [] setup_zero_pages+0x1c/0xb8
[0.00] [] mem_init+0x54/0xa0
[0.00] [] start_kernel+0x204/0x4d8
[0.00] [] kernel_entry+0x0/0x40
[0.00] Code: 02002025  1000f8d9  8e634d7c <34860f80> cc9e
cc9e0020  cc9e0040  cc9e0060  cc9e0080
[0.00]
[0.00] ---[ end trace  ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
...

OE uses qemumips to simulate a Malta board by default.

As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b

The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
...

But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski 
Date:   Wed Nov 23 14:43:49 2016 +0100

MIPS: fix mem=X@Y commandline processing
...

So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.

Author: Hongxu Jia 
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
  and add cases for possible mipsel mips64el ]
Signed-off-by: He Zhe 
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 597e7e9a799..a0c556b8728 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -669,7 +669,7 @@ class BaseConfig(object):
 self.set('QB_MEM', '-m 512')
 
 mach = self.get('MACHINE')
-if mach != 'qemumips':
+if mach != 'qemumips' and mach != 'qemumips64' and mach != 
'qemumipsel' and mach != 'qemumips64el':
 self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
 
 self.qemu_opt_script += ' %s' % self.get('QB_MEM')
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-08 Thread He Zhe

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[0.00] Call Trace:
[0.00] [] clear_page+0x0/0x128
[0.00] [] get_page_from_freelist+0xab8/0xc00
[0.00] [] __alloc_pages_nodemask+0xdc/0xf68
[0.00] [] __get_free_pages+0x18/0x70
[0.00] [] setup_zero_pages+0x1c/0xb8
[0.00] [] mem_init+0x54/0xa0
[0.00] [] start_kernel+0x204/0x4d8
[0.00] [] kernel_entry+0x0/0x40
[0.00] Code: 02002025  1000f8d9  8e634d7c <34860f80> cc9e
cc9e0020  cc9e0040  cc9e0060  cc9e0080
[0.00]
[0.00] ---[ end trace  ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
...

OE uses qemumips to simulate a Malta board by default.

As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b

The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
...

But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski 
Date:   Wed Nov 23 14:43:49 2016 +0100

MIPS: fix mem=X@Y commandline processing
...

So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.

Author: Hongxu Jia 
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
  and make it support all mips cases ]
Signed-off-by: He Zhe 
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 597e7e9a799..73d7d5818bd 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -669,7 +669,7 @@ class BaseConfig(object):
 self.set('QB_MEM', '-m 512')
 
 mach = self.get('MACHINE')
-if mach != 'qemumips':
+if not mach.startswith('qemumips'):
 self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
 
 self.qemu_opt_script += ' %s' % self.get('QB_MEM')
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-08 Thread He Zhe

Please ignore.

On 2018年07月09日 11:07, He Zhe wrote:
> $ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
> ...
> [0.00] Call Trace:
> [0.00] [] clear_page+0x0/0x128
> [0.00] [] get_page_from_freelist+0xab8/0xc00
> [0.00] [] __alloc_pages_nodemask+0xdc/0xf68
> [0.00] [] __get_free_pages+0x18/0x70
> [0.00] [] setup_zero_pages+0x1c/0xb8
> [0.00] [] mem_init+0x54/0xa0
> [0.00] [] start_kernel+0x204/0x4d8
> [0.00] [] kernel_entry+0x0/0x40
> [0.00] Code: 02002025  1000f8d9  8e634d7c <34860f80> cc9e
> cc9e0020  cc9e0040  cc9e0060  cc9e0080
> [0.00]
> [0.00] ---[ end trace  ]---
> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> [0.00] ---[ end Kernel panic - not syncing: Attempted to kill the 
> idle task!
> ...
>
> OE uses qemumips to simulate a Malta board by default.
>
> As upstream qemu introduced:
> https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
>
> The Malta board can support up to 2GiB of RAM which should
> be able to boot a Linux kernel built with CONFIG_HIGHMEM
> enabled and passing "-m 2048" to QEMU and appending the
> following kernel parameters:
> ...
> mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
> ...
>
> But the following commit in kernel broke above mem=X@Y setting
> which added the memory as reserved memory area.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
> ...
> commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
> Author: Marcin Nowakowski 
> Date:   Wed Nov 23 14:43:49 2016 +0100
>
> MIPS: fix mem=X@Y commandline processing
> ...
>
> So remove `mem=*' to disable user-defined physical RAM map
> which let kernel itself caculates memory ranges.
>
> Author: Hongxu Jia 
> [ Merge the two fixes for qemumips32 and qemumips64 into one patch,
>   and make it support all mips cases ]
> Signed-off-by: He Zhe 
> ---
>  scripts/runqemu | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 597e7e9a799..73d7d5818bd 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -669,7 +669,7 @@ class BaseConfig(object):
>  self.set('QB_MEM', '-m 512')
>  
>  mach = self.get('MACHINE')
> -if mach != 'qemumips':
> +if not mach.startswith('qemumips'):
>  self.kernel_cmdline_script += ' mem=%s' % 
> self.get('QB_MEM').replace('-m','').strip() + 'M'
>  
>  self.qemu_opt_script += ' %s' % self.get('QB_MEM')

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] scripts/runqemu: fix qemumips qemumips64 memory detection kernel panic

2018-07-08 Thread He Zhe

$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[0.00] Call Trace:
[0.00] [] clear_page+0x0/0x128
[0.00] [] get_page_from_freelist+0xab8/0xc00
[0.00] [] __alloc_pages_nodemask+0xdc/0xf68
[0.00] [] __get_free_pages+0x18/0x70
[0.00] [] setup_zero_pages+0x1c/0xb8
[0.00] [] mem_init+0x54/0xa0
[0.00] [] start_kernel+0x204/0x4d8
[0.00] [] kernel_entry+0x0/0x40
[0.00] Code: 02002025  1000f8d9  8e634d7c <34860f80> cc9e
cc9e0020  cc9e0040  cc9e0060  cc9e0080
[0.00]
[0.00] ---[ end trace  ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
...

OE uses qemumips to simulate a Malta board by default.

As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b

The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x9000 mem=1536M@0x2000
...

But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski 
Date:   Wed Nov 23 14:43:49 2016 +0100

MIPS: fix mem=X@Y commandline processing
...

So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.

Author: Hongxu Jia 
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
  and make it support all mips cases ]
Signed-off-by: He Zhe 
---
 scripts/runqemu | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index de42d0f3231..73d7d5818bd 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -668,7 +668,10 @@ class BaseConfig(object):
 logger.info('QB_MEM is not set, use 512M by default')
 self.set('QB_MEM', '-m 512')
 
-self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
+mach = self.get('MACHINE')
+if not mach.startswith('qemumips'):
+self.kernel_cmdline_script += ' mem=%s' % 
self.get('QB_MEM').replace('-m','').strip() + 'M'
+
 self.qemu_opt_script += ' %s' % self.get('QB_MEM')
 
 def check_tcpserial(self):
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lttng-tools: Allow reconnect to relayd

2018-07-10 Thread He Zhe

Ping.

Zhe

On 2018年07月04日 18:17, He Zhe wrote:
> If relayd is started after connection attempt from consumerd it will
> leave the session in disconnected state and causes the following
> inconvenience. This is covered by an upstream feature, see
> https://bugs.lttng.org/issues/883. Before it's done, this patches
> allows users to reconnect to relayd.
>
> root@localhost:~# lttng enable-event --userspace --all
> Error: Events: UST create channel failed (channel channel0, session 
> trace_session)
> root@localhost:~# lttng-relayd -b
> Warning: No tracing group detected
> root@localhost:~# lttng enable-event --userspace --all
> Error: Events: UST create channel failed (channel channel0, session 
> trace_session)
>
> Signed-off-by: He Zhe 
> ---
>  ...ow-multiple-attempts-to-connect-to-relayd.patch | 43 
> ++
>  meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb |  1 +
>  2 files changed, 44 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
>
> diff --git 
> a/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
>  
> b/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
> new file mode 100644
> index 000..62a0978592d
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/lttng/lttng-tools/0001-Allow-multiple-attempts-to-connect-to-relayd.patch
> @@ -0,0 +1,43 @@
> +From 70eff899104b86bae02862927c76caaef5de5d3c Mon Sep 17 00:00:00 2001
> +From: Mikael Beckius 
> +Date: Thu, 7 May 2015 16:14:25 +0200
> +Subject: [PATCH] Allow multiple attempts to connect to relayd.
> +
> +It is unclear why a session needs to be made
> +unusable after a failure to connect to relayd
> +since a check for a relayd connection is
> +always made before a session can be configured.
> +
> +The behaviour was introduced in:
> +d9078d0c000d04d49c599a72c1a725026b636ec0
> +
> +Signed-off-by: Mikael Beckius 
> +[ The context has moved, adjust the hunk accordingly ]
> +Signed-off-by: He Zhe 
> +Upstream-Status: Pending
> +---
> + src/bin/lttng-sessiond/cmd.c |8 
> + 1 file changed, 8 deletions(-)
> +
> +diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
> +index 73b4ce3..36f62ee 100644
> +--- a/src/bin/lttng-sessiond/cmd.c
>  b/src/bin/lttng-sessiond/cmd.c
> +@@ -689,14 +689,6 @@ close_sock:
> + free(rsock);
> + 
> + error:
> +-if (ret != LTTNG_OK) {
> +-/*
> +- * The consumer output for this session should not be used 
> anymore
> +- * since the relayd connection failed thus making any tracing 
> or/and
> +- * streaming not usable.
> +- */
> +-consumer->enabled = 0;
> +-}
> + return ret;
> + }
> + 
> +-- 
> +1.7.9.5
> +
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb 
> b/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
> index 93626dd4b5f..e4969c30807 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.9.5.bb
> @@ -30,6 +30,7 @@ PACKAGECONFIG_remove_riscv64 = "lttng-ust"
>  SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
> file://x32.patch \
> file://run-ptest \
> +   file://0001-Allow-multiple-attempts-to-connect-to-relayd.patch \
> "
>  
>  SRC_URI[md5sum] = "051224eb991aee07f8721ff1877d0b96"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cryptodev-linux: Fixes a kernel crash observed with cipher-gcm test.

2018-07-25 Thread He Zhe

Seems this needs updating. The context of cryptiodev-module_1.9.bb has changed.

Thanks,
Zhe

On 2018年07月09日 10:24, Jiping Ma wrote:
> The crypto API for AEAD ciphers changed in recent kernels so that
> associated data is now part of both source and destination scatter
> gathers. The source, destination and associated data buffers need
> to be stiched accordingly for the operations to succeed.
>
> Signed-off-by: Jiping Ma 
> ---
>  .../cryptodev/cryptodev-module_1.9.bb  |   2 +
>  ...inux-split-big-function-to-simplify-maint.patch | 249 
> +
>  ...inux-Fixes-a-kernel-crash-observed-with-c.patch | 115 ++
>  3 files changed, 366 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/cryptodev/files/0001-cryptodev-linux-split-big-function-to-simplify-maint.patch
>  create mode 100644 
> meta/recipes-kernel/cryptodev/files/0002-cryptodev-linux-Fixes-a-kernel-crash-observed-with-c.patch
>
> diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb 
> b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> index 552eb6a..16ac527 100644
> --- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> +++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> @@ -9,6 +9,8 @@ DEPENDS += "cryptodev-linux"
>  
>  SRC_URI += " \
>  file://0001-Disable-installing-header-file-provided-by-another-p.patch \
> +file://0001-cryptodev-linux-split-big-function-to-simplify-maint.patch \
> +file://0002-cryptodev-linux-Fixes-a-kernel-crash-observed-with-c.patch \
>  "
>  
>  EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
> diff --git 
> a/meta/recipes-kernel/cryptodev/files/0001-cryptodev-linux-split-big-function-to-simplify-maint.patch
>  
> b/meta/recipes-kernel/cryptodev/files/0001-cryptodev-linux-split-big-function-to-simplify-maint.patch
> new file mode 100644
> index 000..56a5bb7
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/cryptodev/files/0001-cryptodev-linux-split-big-function-to-simplify-maint.patch
> @@ -0,0 +1,249 @@
> +From 1b0b6cc97ba5cc71ae1385d125256fc1b2d606b0 Mon Sep 17 00:00:00 2001
> +From: Jiping Ma 
> +Date: Wed, 2 May 2018 04:59:32 +
> +Subject: [PATCH 1/2] cryptodev-linux: split big function to simplify
> + maintainance
> +
> +The setup of auth_buf in tls and aead is now duplicated but this
> +is temporary and allows necessary corrections for the aead case
> +with v4.2+ kernels.
> +
> +Upstream-Status: Backported
> +
> +commit 20dcf071bc3076ee7db9d603cfbe6a06e86c7d5f
> +
> +Signed-off-by: Jiping Ma 
> +---
> + authenc.c | 197 
> --
> + 1 file changed, 126 insertions(+), 71 deletions(-)
> +
> +diff --git a/authenc.c b/authenc.c
> +index 1bd7377..28eb0f9 100644
> +--- a/authenc.c
>  b/authenc.c
> +@@ -609,96 +609,151 @@ auth_n_crypt(struct csession *ses_ptr, struct 
> kernel_crypt_auth_op *kcaop,
> + return 0;
> + }
> + 
> +-/* This is the main crypto function - zero-copy edition */
> +-static int
> +-__crypto_auth_run_zc(struct csession *ses_ptr, struct kernel_crypt_auth_op 
> *kcaop)
> ++static int crypto_auth_zc_srtp(struct csession *ses_ptr, struct 
> kernel_crypt_auth_op *kcaop)
> + {
> +-struct scatterlist *dst_sg, *auth_sg, *src_sg;
> ++struct scatterlist *dst_sg, *auth_sg;
> + struct crypt_auth_op *caop = &kcaop->caop;
> +-int ret = 0;
> ++int ret;
> + 
> +-if (caop->flags & COP_FLAG_AEAD_SRTP_TYPE) {
> +-if (unlikely(ses_ptr->cdata.init != 0 &&
> +- (ses_ptr->cdata.stream == 0 ||
> +-  ses_ptr->cdata.aead != 0))) {
> +-derr(0, "Only stream modes are allowed in SRTP mode 
> (but not AEAD)");
> +-return -EINVAL;
> +-}
> ++if (unlikely(ses_ptr->cdata.init != 0 &&
> ++(ses_ptr->cdata.stream == 0 || ses_ptr->cdata.aead != 0))) {
> ++derr(0, "Only stream modes are allowed in SRTP mode (but not 
> AEAD)");
> ++return -EINVAL;
> ++}
> + 
> +-ret = get_userbuf_srtp(ses_ptr, kcaop, &auth_sg, &dst_sg);
> +-if (unlikely(ret)) {
> +-derr(1, "get_userbuf_srtp(): Error getting user 
> pages.");
> +-return ret;
> +-}
> ++ret = get_userbuf_srtp(ses_ptr, kcaop, &auth_sg, &dst_sg);
> ++if (unlikely(ret)) {
> ++derr(1, "get_userbuf_srtp(): Error getting user pages.");
> ++return ret;
> ++}
> + 
> +-ret = srtp_auth_n_crypt(ses_ptr, kcaop, auth_sg, caop->auth_len,
> +-   dst_sg, caop->len);
> ++ret = srtp_auth_n_crypt(ses_ptr, kcaop, auth_sg, caop->auth_len,
> ++dst_sg, caop->len);
> + 
> +-release_user_pages(ses_ptr);
> +-} else { /* TLS and normal cases. Here auth data are usually small
> +-  * so we just copy them to a free page, instead of trying
> +-  * to map them.
> +-  */

Re: [OE-core] [PATCH 10/12] linux-yocto: introduce 4.18 recipes

2018-08-28 Thread He Zhe



On 2018年08月24日 22:59, Bruce Ashfield wrote:
> Introducing the 4.18 kernel as the 'newest' kernel for the oe core
> release.
>
> This update includes tweaked configs, carried forward BSPs, features
> (aufs, yaffs2, preempt-rt) and has been tested on all arches for boot
> and performance sanity.
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb   | 43 +++
>  meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb | 29 +
>  meta/recipes-kernel/linux/linux-yocto_4.18.bb  | 48 
> ++
>  3 files changed, 120 insertions(+)
>  create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
>  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
>  create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.18.bb
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> new file mode 100644
> index ..f740b1dcd892
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.18.bb
> @@ -0,0 +1,43 @@
> +KBRANCH ?= "v4.18/standard/preempt-rt/base"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +# Skip processing of this recipe if it is not explicitly specified as the
> +# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
> +# to build multiple virtual/kernel providers, e.g. as dependency of
> +# core-image-rt-sdk, core-image-rt.
> +python () {
> +if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and 
> d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
> +raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
> linux-yocto-rt to enable it")
> +}
> +
> +SRCREV_machine ?= "8a990322beb7b3aa5a06d7bd630f819b70911587"
> +SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
> +
> +SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> +   
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
> +
> +LINUX_VERSION ?= "4.18.3"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
> +
> +DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
> +DEPENDS += "openssl-native util-linux-native"
> +
> +PV = "${LINUX_VERSION}+git${SRCPV}"
> +
> +KMETA = "kernel-meta"
> +KCONF_BSP_AUDIT_LEVEL = "2"
> +
> +LINUX_KERNEL_TYPE = "preempt-rt"
> +
> +COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"

Should qemuarm64 be in here?

Zhe

> +
> +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
> +
> +# Functionality flags
> +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
> features/taskstats/taskstats.scc"
> +KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
> +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
> +KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> +KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> new file mode 100644
> index ..1f0b35ec25ec
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb
> @@ -0,0 +1,29 @@
> +KBRANCH ?= "v4.18/standard/tiny/common-pc"
> +LINUX_KERNEL_TYPE = "tiny"
> +KCONFIG_MODE = "--allnoconfig"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +LINUX_VERSION ?= "4.18.3"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
> +
> +DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
> +DEPENDS += "openssl-native util-linux-native"
> +
> +KMETA = "kernel-meta"
> +KCONF_BSP_AUDIT_LEVEL = "2"
> +
> +SRCREV_machine ?= "eba03655e8e436ef6090100423bcea43e4911478"
> +SRCREV_meta ?= "1f78e20cc98dd46637c0beb6007214fb3650992c"
> +
> +PV = "${LINUX_VERSION}+git${SRCPV}"
> +
> +SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> +   
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.18;destsuffix=${KMETA}"
> +
> +COMPATIBLE_MACHINE = "qemux86|qemux86-64"
> +
> +# Functionality flags
> +KERNEL_FEATURES = ""
> +
> +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.18.bb 
> b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
> new file mode 100644
> index ..b42c124c87da
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.18.bb
> @@ -0,0 +1,48 @@
> +KBRANCH ?= "v4.18/standard/base"
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +# board specific branches
> +KBRANCH_qemuarm  ?= "v4.18/standard/arm-versatile-926ejs"
> +KBRANCH_qemuarm64 ?= "v4.18/standard/qemuarm64"
> +KBRANCH_qemumips ?= "v4.18/standard/mti-malta32"
> +KBRANCH_qemuppc  ?= "v4.18/standard/qemuppc"
> +KBRANCH_qemux86  ?= "v4.18/standard/base"
> +KBRANCH_qemux86-64 ?= "v4.18/standard/base"
> +KBRANCH_qemumips64 ?= "v4.18/standard/mti-

Re: [OE-core] [PATCH] qemux86 qemux86-64: Enable pci

2017-08-08 Thread He Zhe

Ping.

On 2017年07月31日 21:11, zhe...@windriver.com wrote:
> From: He Zhe 
>
> lspci and some other software require "pci" in MACHINE_FEATURES and PCI
> is valid in the qemux86* context.
>
> Signed-off-by: He Zhe 
> ---
>  meta/conf/machine/qemux86-64.conf | 2 +-
>  meta/conf/machine/qemux86.conf| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/machine/qemux86-64.conf 
> b/meta/conf/machine/qemux86-64.conf
> index 4f30033..9f78191 100644
> --- a/meta/conf/machine/qemux86-64.conf
> +++ b/meta/conf/machine/qemux86-64.conf
> @@ -28,7 +28,7 @@ XSERVER = "xserver-xorg \
> xserver-xorg-module-libint10 \
> "
>  
> -MACHINE_FEATURES += "x86"
> +MACHINE_FEATURES += "x86 pci"
>  
>  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>  
> diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
> index e232947..d778fa7 100644
> --- a/meta/conf/machine/qemux86.conf
> +++ b/meta/conf/machine/qemux86.conf
> @@ -27,7 +27,7 @@ XSERVER = "xserver-xorg \
> xserver-xorg-module-libint10 \
> "
>  
> -MACHINE_FEATURES += "x86"
> +MACHINE_FEATURES += "x86 pci"
>  
>  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>  

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] nativesdk-bison: Add to nativesdk-packagegroup-sdk-host and set BISON_PKGDATADIR

2018-09-27 Thread He Zhe

Please ignore. Something wrong with it.

Zhe

On 2018年09月27日 16:38, zhe...@windriver.com wrote:
> From: He Zhe 
>
> bison is needed when building kernel. Add it to 
> nativesdk-packagegroup-sdk-host
> and set BISON_PKGDATADIR for bison to use its components.
>
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
>  meta/recipes-devtools/bison/bison_3.0.4.bb | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git 
> a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
> b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> index e2f6169..448c2f6 100644
> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> @@ -25,6 +25,7 @@ RDEPENDS_${PN} = "\
>  nativesdk-cmake \
>  ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
> '', d)} \
>  nativesdk-sdk-provides-dummy \
> +nativesdk-bison \
>  "
>  
>  RDEPENDS_${PN}_darwin = "\
> diff --git a/meta/recipes-devtools/bison/bison_3.0.4.bb 
> b/meta/recipes-devtools/bison/bison_3.0.4.bb
> index cc155f0..07677a7 100644
> --- a/meta/recipes-devtools/bison/bison_3.0.4.bb
> +++ b/meta/recipes-devtools/bison/bison_3.0.4.bb
> @@ -36,4 +36,8 @@ do_install_append_class-native() {
>   create_wrapper ${D}/${bindir}/bison \
>   BISON_PKGDATADIR=${STAGING_DATADIR_NATIVE}/bison
>  }
> +do_install_append_class-nativesdk() {
> + create_wrapper ${D}/${bindir}/bison \
> + 
> BISON_PKGDATADIR=${OECORE_NATIVE_SYSROOT}${prefix_nativesdk}/share/bison
> +}
>  BBCLASSEXTEND = "native nativesdk"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1 V2] sigwaitinfo01: recent glibc calls syscall directly

2018-09-28 Thread He Zhe

Ping.

Zhe

On 2018年09月21日 14:09, Hongzhi.Song wrote:
> v2:
> modify the format of [Upstream-Status]
>
> Hongzhi.Song (1):
>   sigwaitinfo01: recent glibc calls syscall directly
>
>  ...nfo01-recent-glibc-calls-syscall-directly.patch | 75 
> ++
>  meta/recipes-extended/ltp/ltp_20180515.bb  |  1 +
>  2 files changed, 76 insertions(+)
>  create mode 100644 
> meta/recipes-extended/ltp/ltp/0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] scripts: Use fixed temporary file instead of pipe for here-doc

2018-11-21 Thread He Zhe

On 2018/11/21 18:07, Richard Purdie wrote:
> On Wed, 2018-11-21 at 17:39 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> A workaround for possible "*** Compiler lacks asm-goto support..
>> Stop."
>> linux-libc-headers is built by gcc on build machine, which could not
>> contain the
>> fix.
>>
>> Signed-off-by: He Zhe 
>> ---
>>  ...-fixed-temporary-file-instead-of-pipe-for.patch | 60
>> ++
>>  .../linux-libc-headers/linux-libc-headers_4.18.bb  |  4 ++
>>  2 files changed, 64 insertions(+)
>>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-
>> libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-
>> for.patch
> How old is an "old gcc"?

I put the full explanation in the commit log of the patch inside.

The fix below for the bug has not been released from upstream. Since there has
not been gcc-cross when building linux-libc-headers, we have to use build
machine gcc which could not contain the fix for the moment. To work around the
error, we create a fixed temporary file to contain the program being tested.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
2a50366ded329bfb39d387253450c9d5302c3503

>
> If this isn't going upstream, I'm not sure we want to take and carry
> this either. Unless this is a gcc people would commonly run into I'm
> tempted not to take this.

This is a gcc issue, but the fix would not quickly goto versions being used
by users. So this patch is used as a workaround to prevent the failure.

To be specific, we encountered this in docker where the /tmp could be
rarely used that very low number inode may be allocated and triggers
the error.

>
> Also, your patch subject is wrong as this does not change our scripts
> directory.

If this is OK, I'll send v2 to change the subject.

Thanks,
Zhe

>
> Cheers,
>
> Richard
>
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] linux-libc-headers: Fix build failure by using fixed temporary file instead of pipe

2018-12-05 Thread He Zhe

Kindly ping.

Zhe

On 2018/11/21 22:06, zhe...@windriver.com wrote:
> From: He Zhe 
>
> This is a workaround for the following possible build failure.
>
> *** Compiler lacks asm-goto support.. Stop.
>
> When building linux-libc-headers we need to use binutils on build machine.
> binutils v2.31 introduces a bug that could cause scripts/gcc-goto.sh to fail
> when running in an environment where /tmp is rarely used, e.g. in docker.
>
> Signed-off-by: He Zhe 
> ---
> v2: Improve commit log
> v3: Shorten long lines as patchwork suggested
> v4: Shorten subject line...
>
>  ...-fixed-temporary-file-instead-of-pipe-for.patch | 70 
> ++
>  .../linux-libc-headers/linux-libc-headers_4.18.bb  |  4 ++
>  2 files changed, 74 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>  
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
> new file mode 100644
> index 000..0d8fa80
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
> @@ -0,0 +1,70 @@
> +From 3bbea65e11918f8753e8006a2198b999cdb0af58 Mon Sep 17 00:00:00 2001
> +From: He Zhe 
> +Date: Wed, 21 Nov 2018 15:12:43 +0800
> +Subject: [PATCH] scripts: Use fixed temporary file instead of pipe for
> + here-doc
> +
> +There was a bug of "as" in binutils that when it checks if the input file and
> +output file are the same one, it would not check if they are on the same 
> block
> +device. The check is introduced by the following commit in v2.31.
> +
> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
> +67f846b59b32f3d704c601669409c2584383fea9
> +
> +The here-doc usage in this script creates temporary file in /tmp. When we 
> run in
> +an environment where /tmp has rarely been used, the newly created temporary 
> file
> +may have a very low inode number. If the inode number was 6 which is the 
> same as
> +/dev/null, the as would wrongly think the input file and the output file are 
> the
> +same and report the following error.
> +
> +*** Compiler lacks asm-goto support.. Stop.
> +
> +One observed case happened in docker where the /tmp could be so rarely used 
> that
> +very low number inode may be allocated and triggers the error.
> +
> +The fix below for the bug only exists on the master branch of binutils so far
> +and has not been released from upstream. As the convict is introduced since
> +v2.31, only v2.31 is affected.
> +
> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
> +2a50366ded329bfb39d387253450c9d5302c3503
> +
> +When building linux-libc-headers we need to use "as" in binutils which does 
> not
> +contain the fix for the moment. To work around the error, we create a fixed
> +temporary file to contain the program being tested.
> +
> +This patch also removes ">/dev/null 2>&1" so we will have more direct error
> +information in case something else wrong happened.
> +
> +Upstream-Status: Inappropriate [A work around for binutils v2.31]
> +
> +Signed-off-by: He Zhe 
> +---
> + scripts/gcc-goto.sh | 7 ++-
> + 1 file changed, 6 insertions(+), 1 deletion(-)
> +
> +diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
> +index 083c526..0aaf1b4 100755
> +--- a/scripts/gcc-goto.sh
>  b/scripts/gcc-goto.sh
> +@@ -3,7 +3,9 @@
> + # Test for gcc 'asm goto' support
> + # Copyright (C) 2010, Jason Baron 
> + 
> +-cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
> ++TMPFILE=`mktemp -p .`
> ++
> ++cat << "END" > ${TMPFILE}
> + int main(void)
> + {
> + #if defined(__arm__) || defined(__aarch64__)
> +@@ -20,3 +22,6 @@ entry:
> + return 0;
> + }
> + END
> ++
> ++$@ -x c ${TMPFILE} -c -o /dev/null && echo "y"
> ++rm ${TMPFILE}
> +-- 
> +2.7.4
> +
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
> index eb7bee7..00420aa 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
> @@ -9,5 +9,9 @@ SRC_URI_append_libc-musl = "\
>  file://0001-include-linux-stddef.h-in-swab.h-uapi-header.patch \
> "
>  
> +SRC_URI_append = "\
> +file://0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch \
> +"
> +
>  SRC_URI[md5sum] = "bee5fe53ee1c3142b8f0c12c0d3348f9"
>  SRC_URI[sha256sum] = 
> "19d8bcf49ef530cd4e364a45b4a22fa70714b70349c8100e7308488e26f1eaf1"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] linux-libc-headers: Fix build failure by using fixed temporary file instead of pipe

2018-12-10 Thread He Zhe



On 2018/12/11 00:58, Bruce Ashfield wrote:
>
>
> On Wed, Nov 21, 2018 at 9:06 AM  <mailto:zhe...@windriver.com>> wrote:
>
> From: He Zhe mailto:zhe...@windriver.com>>
>
> This is a workaround for the following possible build failure.
>
> *** Compiler lacks asm-goto support.. Stop.
>
> When building linux-libc-headers we need to use binutils on build machine.
> binutils v2.31 introduces a bug that could cause scripts/gcc-goto.sh to 
> fail
> when running in an environment where /tmp is rarely used, e.g. in docker.
>
> Signed-off-by: He Zhe mailto:zhe...@windriver.com>>
> ---
> v2: Improve commit log
> v3: Shorten long lines as patchwork suggested
> v4: Shorten subject line...
>
>  ...-fixed-temporary-file-instead-of-pipe-for.patch | 70 
> ++
>  .../linux-libc-headers/linux-libc-headers_4.18.bb 
> <http://linux-libc-headers_4.18.bb>  |  4 ++
>  2 files changed, 74 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>  
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
> new file mode 100644
> index 000..0d8fa80
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
> @@ -0,0 +1,70 @@
> +From 3bbea65e11918f8753e8006a2198b999cdb0af58 Mon Sep 17 00:00:00 2001
> +From: He Zhe mailto:zhe...@windriver.com>>
> +Date: Wed, 21 Nov 2018 15:12:43 +0800
> +Subject: [PATCH] scripts: Use fixed temporary file instead of pipe for
> + here-doc
> +
> +There was a bug of "as" in binutils that when it checks if the input 
> file and
> +output file are the same one, it would not check if they are on the same 
> block
> +device. The check is introduced by the following commit in v2.31.
> +
> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
> +67f846b59b32f3d704c601669409c2584383fea9 
> <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=+67f846b59b32f3d704c601669409c2584383fea9>
>
>
> Can you double check the links to the upstream changes ? They didn't work
> for me.

I guess that's due to the leading "+" prepended to the second line of the link.
It's part of the patch, not of the link.

>
>  
>
> +
> +The here-doc usage in this script creates temporary file in /tmp. When 
> we run in
> +an environment where /tmp has rarely been used, the newly created 
> temporary file
> +may have a very low inode number. If the inode number was 6 which is the 
> same as
> +/dev/null, the as would wrongly think the input file and the output file 
> are the
> +same and report the following error.
> +
> +*** Compiler lacks asm-goto support.. Stop.
> +
> +One observed case happened in docker where the /tmp could be so rarely 
> used that
> +very low number inode may be allocated and triggers the error.
> +
> +The fix below for the bug only exists on the master branch of binutils 
> so far
> +and has not been released from upstream. As the convict is introduced 
> since
> +v2.31, only v2.31 is affected.
> +
> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
> +2a50366ded329bfb39d387253450c9d5302c3503 
> <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=+2a50366ded329bfb39d387253450c9d5302c3503>
> +
> +When building linux-libc-headers we need to use "as" in binutils which 
> does not
> +contain the fix for the moment. To work around the error, we create a 
> fixed
> +temporary file to contain the program being tested.
> +
> +This patch also removes ">/dev/null 2>&1" so we will have more direct 
> error
> +information in case something else wrong happened.
> +
> +Upstream-Status: Inappropriate [A work around for binutils v2.31]
>
>
> It would be nice to have a way to test for the host binutils version, since 
> without it
> we have no way to know when we can stop carrying this change. 
>
> Not that the change is all that complex or should cause any problems, it is 
> just
> very open ended without a check.
>
> Did you look into any conditional way to test the b

Re: [OE-core] [PATCH v4] linux-libc-headers: Fix build failure by using fixed temporary file instead of pipe

2018-12-11 Thread He Zhe




On 2018/12/11 22:17, Bruce Ashfield wrote:
> On Tue, Dec 11, 2018 at 2:49 AM He Zhe  wrote:
>>
>>
>> On 2018/12/11 00:58, Bruce Ashfield wrote:
>>>
>>> On Wed, Nov 21, 2018 at 9:06 AM >> <mailto:zhe...@windriver.com>> wrote:
>>>
>>> From: He Zhe mailto:zhe...@windriver.com>>
>>>
>>> This is a workaround for the following possible build failure.
>>>
>>> *** Compiler lacks asm-goto support.. Stop.
>>>
>>> When building linux-libc-headers we need to use binutils on build 
>>> machine.
>>> binutils v2.31 introduces a bug that could cause scripts/gcc-goto.sh to 
>>> fail
>>> when running in an environment where /tmp is rarely used, e.g. in 
>>> docker.
>>>
>>> Signed-off-by: He Zhe >> <mailto:zhe...@windriver.com>>
>>> ---
>>> v2: Improve commit log
>>> v3: Shorten long lines as patchwork suggested
>>> v4: Shorten subject line...
>>>
>>>  ...-fixed-temporary-file-instead-of-pipe-for.patch | 70 
>>> ++
>>>  .../linux-libc-headers/linux-libc-headers_4.18.bb 
>>> <http://linux-libc-headers_4.18.bb>  |  4 ++
>>>  2 files changed, 74 insertions(+)
>>>  create mode 100644 
>>> meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>>>
>>> diff --git 
>>> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>>>  
>>> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>>> new file mode 100644
>>> index 000..0d8fa80
>>> --- /dev/null
>>> +++ 
>>> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
>>> @@ -0,0 +1,70 @@
>>> +From 3bbea65e11918f8753e8006a2198b999cdb0af58 Mon Sep 17 00:00:00 2001
>>> +From: He Zhe mailto:zhe...@windriver.com>>
>>> +Date: Wed, 21 Nov 2018 15:12:43 +0800
>>> +Subject: [PATCH] scripts: Use fixed temporary file instead of pipe for
>>> + here-doc
>>> +
>>> +There was a bug of "as" in binutils that when it checks if the input 
>>> file and
>>> +output file are the same one, it would not check if they are on the 
>>> same block
>>> +device. The check is introduced by the following commit in v2.31.
>>> +
>>> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
>>> +67f846b59b32f3d704c601669409c2584383fea9 
>>> <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=+67f846b59b32f3d704c601669409c2584383fea9>
>>>
>>>
>>> Can you double check the links to the upstream changes ? They didn't work
>>> for me.
>> I guess that's due to the leading "+" prepended to the second line of the 
>> link.
>> It's part of the patch, not of the link.
> That's not what I'm seeing. Even when I select and paste the link, I'm getting
> a:  "400 - Invalid hash parameter" back from the upstream git repo.
>
>>>
>>>
>>> +
>>> +The here-doc usage in this script creates temporary file in /tmp. When 
>>> we run in
>>> +an environment where /tmp has rarely been used, the newly created 
>>> temporary file
>>> +may have a very low inode number. If the inode number was 6 which is 
>>> the same as
>>> +/dev/null, the as would wrongly think the input file and the output 
>>> file are the
>>> +same and report the following error.
>>> +
>>> +*** Compiler lacks asm-goto support.. Stop.
>>> +
>>> +One observed case happened in docker where the /tmp could be so rarely 
>>> used that
>>> +very low number inode may be allocated and triggers the error.
>>> +
>>> +The fix below for the bug only exists on the master branch of binutils 
>>> so far
>>> +and has not been released from upstream. As the convict is introduced 
>>> since
>>> +v2.31, only v2.31 is affected.
>>> +
>>> +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=
>>> +2a50366ded329bfb39d387253450c9d5302c35

Re: [OE-core] [PATCH 1/1] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

2016-02-18 Thread He Zhe



On 02/18/2016 11:37 AM, Andre McCurdy wrote:
> On Wed, Feb 17, 2016 at 2:01 AM,   wrote:
>> From: He Zhe 
>>
>> Add KERNEL_IMAGETYPES to support building packaging and installing
>> multi types of kernel images, such as zImage uImage, at one time.
>> KERNEL_IMAGETYPE works as before.
>>
>> Fixes [YOCTO #6945].
>>
>> Signed-off-by: He Zhe 
>> ---
>>  meta/classes/kernel-fitimage.bbclass|  20 ++--
>>  meta/classes/kernel-grub.bbclass|  44 ++---
>>  meta/classes/kernel-uimage.bbclass  |  22 +++--
>>  meta/classes/kernel.bbclass | 169 
>> ++--
>>  meta/conf/documentation.conf|   1 +
>>  meta/recipes-kernel/linux/linux-dtb.inc |  49 +
>>  6 files changed, 202 insertions(+), 103 deletions(-)
>>
>> diff --git a/meta/classes/kernel-fitimage.bbclass 
>> b/meta/classes/kernel-fitimage.bbclass
>> index f1b409c..51df19d 100644
>> --- a/meta/classes/kernel-fitimage.bbclass
>> +++ b/meta/classes/kernel-fitimage.bbclass
>> @@ -1,8 +1,8 @@
>>  inherit kernel-uboot
>>
>>  python __anonymous () {
>> -kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
>> -if kerneltype == 'fitImage':
>> +kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
>> +if 'fitImage' in kerneltypes.split():
>>  depends = d.getVar("DEPENDS", True)
>>  depends = "%s u-boot-mkimage-native dtc-native" % depends
>>  d.setVar("DEPENDS", depends)
>> @@ -10,7 +10,9 @@ python __anonymous () {
>> # Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
>> # to kernel.bbclass . We have to override it, since we pack zImage
>> # (at least for now) into the fitImage .
>> -d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
>> +typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
>> +if 'fitImage' in typeformake.split():
>> +d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
>> typeformake.replace('fitImage', 'zImage'))
>>
>>  image = d.getVar('INITRAMFS_IMAGE', True)
>>  if image:
>> @@ -154,7 +156,7 @@ EOF
>>  }
>>
>>  do_assemble_fitimage() {
>> -   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
>> +   if echo ${KERNEL_IMAGETYPES} | grep -Pq "\bfitImage\b"; then
>> kernelcount=1
>> dtbcount=""
>> rm -f fit-image.its
>> @@ -217,14 +219,14 @@ addtask assemble_fitimage before do_install after 
>> do_compile
>>
>>  kernel_do_deploy_append() {
>> # Update deploy directory
>> -   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
>> +   if echo ${KERNEL_IMAGETYPES} | grep -Pq "\bfitImage\b"; then
>> cd ${B}
>> echo "Copying fit-image.its source file..."
>> -   
>> its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
>> -   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
>> +   
>> its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
>> +   its_symlink_name=fitImage-its-${MACHINE}
>> install -m 0644 fit-image.its 
>> ${DEPLOYDIR}/${its_base_name}.its
>> -   
>> linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
>> -   
>> linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
>> +   
>> linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
>> +   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
>> install -m 0644 linux.bin 
>> ${DEPLOYDIR}/${linux_bin_base_name}.bin
>>
>> cd ${DEPLOYDIR}
>> diff --git a/meta/classes/kernel-grub.bbclass 
>> b/meta/classes/kernel-grub.bbclass
>> index a63f482..f7dcc07 100644
>> --- a/meta/classes/kernel-grub.bbclass
>> +++ b/meta/classes/kernel-grub.bbclass
>> @@ -10,41 +10,44 @@
>>  #   updates the new kernel as the boot priority.
>>  #
>>
>> -pkg_preinst_kernel-image_append () {
>> +python __anonymous () {
>> +import re
>> +
>> +preinst = '''
>> # Parsing confliction
>>

Re: [OE-core] [PATCH 1/1] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

2016-02-18 Thread He Zhe



On 02/18/2016 04:15 PM, Andrea Adami wrote:
> On Thu, Feb 18, 2016 at 4:37 AM, Andre McCurdy  wrote:
>> On Wed, Feb 17, 2016 at 2:01 AM,   wrote:
>>> From: He Zhe 
>>>
>>> Add KERNEL_IMAGETYPES to support building packaging and installing
>>> multi types of kernel images, such as zImage uImage, at one time.
>>> KERNEL_IMAGETYPE works as before.
>>>
>>> Fixes [YOCTO #6945].
>>>
>>> Signed-off-by: He Zhe 
>>> ---
>>>  meta/classes/kernel-fitimage.bbclass|  20 ++--
>>>  meta/classes/kernel-grub.bbclass|  44 ++---
>>>  meta/classes/kernel-uimage.bbclass  |  22 +++--
>>>  meta/classes/kernel.bbclass | 169 
>>> ++--
>>>  meta/conf/documentation.conf|   1 +
>>>  meta/recipes-kernel/linux/linux-dtb.inc |  49 +
>>>  6 files changed, 202 insertions(+), 103 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel-fitimage.bbclass 
>>> b/meta/classes/kernel-fitimage.bbclass
>>> index f1b409c..51df19d 100644
>>> --- a/meta/classes/kernel-fitimage.bbclass
>>> +++ b/meta/classes/kernel-fitimage.bbclass
>>> @@ -1,8 +1,8 @@
>>>  inherit kernel-uboot
>>>
>>>  python __anonymous () {
>>> -kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
>>> -if kerneltype == 'fitImage':
>>> +kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
>>> +if 'fitImage' in kerneltypes.split():
>>>  depends = d.getVar("DEPENDS", True)
>>>  depends = "%s u-boot-mkimage-native dtc-native" % depends
>>>  d.setVar("DEPENDS", depends)
>>> @@ -10,7 +10,9 @@ python __anonymous () {
>>> # Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
>>> # to kernel.bbclass . We have to override it, since we pack zImage
>>> # (at least for now) into the fitImage .
>>> -d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
>>> +typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
>>> +if 'fitImage' in typeformake.split():
>>> +d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
>>> typeformake.replace('fitImage', 'zImage'))
>>>
>>>  image = d.getVar('INITRAMFS_IMAGE', True)
>>>  if image:
>>> @@ -154,7 +156,7 @@ EOF
>>>  }
>>>
>>>  do_assemble_fitimage() {
>>> -   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
>>> +   if echo ${KERNEL_IMAGETYPES} | grep -Pq "\bfitImage\b"; then
>>> kernelcount=1
>>> dtbcount=""
>>> rm -f fit-image.its
>>> @@ -217,14 +219,14 @@ addtask assemble_fitimage before do_install after 
>>> do_compile
>>>
>>>  kernel_do_deploy_append() {
>>> # Update deploy directory
>>> -   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
>>> +   if echo ${KERNEL_IMAGETYPES} | grep -Pq "\bfitImage\b"; then
>>> cd ${B}
>>> echo "Copying fit-image.its source file..."
>>> -   
>>> its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>> -   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
>>> +   
>>> its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>> +   its_symlink_name=fitImage-its-${MACHINE}
>>> install -m 0644 fit-image.its 
>>> ${DEPLOYDIR}/${its_base_name}.its
>>> -   
>>> linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>> -   
>>> linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
>>> +   
>>> linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>> +   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
>>> install -m 0644 linux.bin 
>>> ${DEPLOYDIR}/${linux_bin_base_name}.bin
>>>
>>> cd ${DEPLOYDIR}
>>> diff --git a/meta/classes/kernel-grub.bbclass 
>>> b/meta/classes/kernel-grub.bbclass
>>> index a63f482..f7dcc07 100644
>&

Re: [OE-core] [PATCH v2 1/2] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

2016-02-22 Thread He Zhe



On 02/19/2016 11:46 PM, Bruce Ashfield wrote:
>
>
> On Fri, Feb 19, 2016 at 4:56 AM,  <mailto:zhe...@windriver.com>>wrote:
>
> From: He Zhe mailto:zhe...@windriver.com>>
>
> Add KERNEL_IMAGETYPES to support building packaging and installing
> multi types of kernel images, such as zImage uImage, at one time.
>
> KERNEL_IMAGETYPE works as before. All KERNEL_ALT_IMAGETYPEs are
> replaced by KERNEL_IMAGETYPES.
>
>
>  
> I see that you have updated layers/configs with the new variable, but 
> obviously you can't see all the 
> layers that may be using that old variable.
>
> Isn't it possible to have a python routine that detects the old ALT_IMAGETYPE 
> variable and
> assigns it to the new one (if it isn't already set) ? Sort of like how distro 
> features/features backfill
> work ?
>

Thanks for careful review.

OK. I'll try to add such function.

>
> Fixes [YOCTO #6945].
>
> Signed-off-by: He Zhe mailto:zhe...@windriver.com>>
> ---
>  documentation/ref-manual/ref-variables.xml |  10 +-
>  meta-yocto-bsp/conf/machine/edgerouter.conf|   2 +-
>  meta/classes/kernel-fitimage.bbclass   |  20 +--
>  meta/classes/kernel-grub.bbclass   |  44 --
>  meta/classes/kernel-uimage.bbclass |  22 +--
>  meta/classes/kernel.bbclass| 171 
> +++--
>  meta/conf/documentation.conf   |   1 +
>  meta/conf/machine/qemumips.conf|   2 +-
>  meta/conf/machine/qemumips64.conf  |   2 +-
>  meta/recipes-kernel/linux/linux-dtb.inc|  49 +++---
>  .../target/arch/mips/conf/machine/machine.conf |   2 +-
>  .../target/arch/mips64/conf/machine/machine.conf   |   2 +-
>  .../target/arch/qemu/conf/machine/machine.conf |   2 +-
>  13 files changed, 214 insertions(+), 115 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml 
> b/documentation/ref-manual/ref-variables.xml
> index a76a8c2..a8e4fd8 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -6417,14 +6417,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR 
> = "${INC_PR}.3"
>  
>  
>
> - id='var-KERNEL_ALT_IMAGETYPE'>KERNEL_ALT_IMAGETYPE
> + id='var-KERNEL_IMAGETYPES'>KERNEL_IMAGETYPES
>  
> -KERNEL_ALT_IMAGETYPE[doc] = "Specifies an alternate 
> kernel image type for creation."
> +KERNEL_IMAGETYPES[doc] = "Specifies alternate kernel 
> image types for creation."
>  
>  
>  
>  
> -Specifies an alternate kernel image type for 
> creation in
> +Specifies alternate kernel image types for creation 
> in
>  addition to the kernel image type specified using the
>   linkend='var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE
>  variable.
> @@ -6612,8 +6612,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
> "${INC_PR}.3"
>  
>
>  
> -If you want to build an alternate kernel image type, 
> use the
> - linkend='var-KERNEL_ALT_IMAGETYPE'>KERNEL_ALT_IMAGETYPE
> +If you want to build alternate kernel image types, 
> use the
> + linkend='var-KERNEL_IMAGETYPES'>KERNEL_IMAGETYPES
>  variable.
>  
>  
> diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf 
> b/meta-yocto-bsp/conf/machine/edgerouter.conf
> index 476e690..affd568 100644
> --- a/meta-yocto-bsp/conf/machine/edgerouter.conf
> +++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
> @@ -7,7 +7,7 @@ require conf/machine/include/tune-mips64.inc
>  MACHINE_FEATURES = "pci ext2 ext3 serial"
>
>  KERNEL_IMAGETYPE = "vmlinux"
> -KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
> +KERNEL_IMAGETYPES = "vmlinux.bin"
>
>
> This now reads a bit ... odd (for back of a better description). I'm 
> concerned that it will cause
> confusion, there are two variables:
>
> KERNEL_IMAGETYPE and KERNEL_IMAGETYPES ..
>
> They are very close in name, and just reading the variable doesn't really

Re: [OE-core] [PATCH v3 0/2] Yocto Bug #6945

2016-03-10 Thread He Zhe

Any more comments?

Thanks,
Zhe

On 02/24/2016 08:20 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> v1 to v2:
>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
>  - Update related doc files
>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
>  - Link built vmlinuz to boot directory for reference
>
> v2 to v3:
>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order that 
> users can still use the old variables.
>  - Run oe_rummake in a loop for every types so that we can add different 
> configurations to them easily in the future.
>  - Warn, intead of die, users if one of the types are over the size limit.
>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
>  - Remove the doc parts. They will be submitted yocto-docs later.
>  - Change some grep usage to make it more clear.
>  - Correct a typo.
>
> The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:
>
>   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib zhe/yocto-bug-6945
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/yocto-bug-6945
>
> for you to fetch changes up to dc52a1efbb8248ea274a1cd0cca5734290b3025f:
>
>   kernel: Make symbol link to vmlinuz in boot directory (2016-02-24 07:08:16 
> -0500)
>
> 
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ---
>  meta/classes/kernel-grub.bbclass  |  44 
> +---
>  meta/classes/kernel-uimage.bbclass|  22 
>  meta/classes/kernel.bbclass   | 187 
> ---
>  meta/conf/documentation.conf  |   3 ++-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
> ++++++++++--
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 218 insertions(+), 109 deletions(-)
>
> He Zhe (2):
>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>   kernel: Make symbol link to vmlinuz in boot directory
>
>  meta/classes/kernel-fitimage.bbclass  |  20 ++--
>  meta/classes/kernel-grub.bbclass  |  44 ---
>  meta/classes/kernel-uimage.bbclass|  22 ++--
>  meta/classes/kernel.bbclass   | 187 
> +-
>  meta/conf/documentation.conf  |   3 +-
>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 +---
>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>  7 files changed, 218 insertions(+), 109 deletions(-)
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 0/2] Yocto Bug #6945

2016-03-21 Thread He Zhe

Ping.

Thanks,
Zhe

On 03/11/2016 11:32 AM, He Zhe wrote:
> Any more comments?
>
> Thanks,
> Zhe
>
> On 02/24/2016 08:20 PM, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> v1 to v2:
>>  - Change KERNEL_OUTPUT to KERNEL_OUTPUT_DIR and update comments
>>  - Update related doc files
>>  - Replace all KERNEL_ALT_IMAGETYPEs with KERNEL_IMAGETYPES
>>  - Link built vmlinuz to boot directory for reference
>>
>> v2 to v3:
>>  - Merge existing KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES in order that 
>> users can still use the old variables.
>>  - Run oe_rummake in a loop for every types so that we can add different 
>> configurations to them easily in the future.
>>  - Warn, intead of die, users if one of the types are over the size limit.
>>  - Remove the replacement of KERNEL_ALT_IMAGETYPE in v2.
>>  - Remove the doc parts. They will be submitted yocto-docs later.
>>  - Change some grep usage to make it more clear.
>>  - Correct a typo.
>>
>> The following changes since commit 23056103c949b498c23b47579e8dd57ce78e6ed9:
>>
>>   uclibc: Do not use immediate expansion operator (2016-02-22 20:42:48 +)
>>
>> are available in the git repository at:
>>
>>   git://git.yoctoproject.org/poky-contrib zhe/yocto-bug-6945
>>   
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/yocto-bug-6945
>>
>> for you to fetch changes up to dc52a1efbb8248ea274a1cd0cca5734290b3025f:
>>
>>   kernel: Make symbol link to vmlinuz in boot directory (2016-02-24 07:08:16 
>> -0500)
>>
>> 
>> He Zhe (2):
>>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>>   kernel: Make symbol link to vmlinuz in boot directory
>>
>>  meta/classes/kernel-fitimage.bbclass  |  20 ---
>>  meta/classes/kernel-grub.bbclass  |  44 
>> +---
>>  meta/classes/kernel-uimage.bbclass|  22 
>>  meta/classes/kernel.bbclass   | 187 
>> -----------
>>  meta/conf/documentation.conf  |   3 ++-
>>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 
>> ++--
>>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>>  7 files changed, 218 insertions(+), 109 deletions(-)
>>
>> He Zhe (2):
>>   kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time
>>   kernel: Make symbol link to vmlinuz in boot directory
>>
>>  meta/classes/kernel-fitimage.bbclass  |  20 ++--
>>  meta/classes/kernel-grub.bbclass  |  44 ---
>>  meta/classes/kernel-uimage.bbclass|  22 ++--
>>  meta/classes/kernel.bbclass   | 187 
>> +-
>>  meta/conf/documentation.conf  |   3 +-
>>  meta/recipes-kernel/linux/linux-dtb.inc   |  49 +---
>>  meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
>>  7 files changed, 218 insertions(+), 109 deletions(-)
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bash2dash conversion

2016-09-22 Thread He Zhe



On 09/19/2016 07:57 PM, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> zhe...@windriver.com
>> Sent: den 18 september 2016 04:52
>> To: openembedded-core@lists.openembedded.org
>> Subject: [OE-core] [PATCH] bash2dash conversion
>  ^
> Typically this is referred to as "Remove bashisms"...

Yes.

>
>> From: "Tim K. Chan" 
>>
>> Change bash style to dash style
>>
>> Signed-off-by: Tim K. Chan 
>> [Adjust context]
>> Signed-off-by: He Zhe 
>> ---
>>  meta/classes/systemd.bbclass|  4 ++--
>>  meta/classes/update-rc.d.bbclass|  6 +++---
>>  meta/classes/useradd_base.bbclass   |  4 ++--
>>  meta/recipes-connectivity/resolvconf/resolvconf_1.79.bb |  2 +-
>>  meta/recipes-core/glibc/glibc-package.inc   |  2 +-
>>  meta/recipes-devtools/guile/guile_2.0.12.bb |  6 --
>>  meta/recipes-devtools/rpm/rpm_5.4.16.bb | 13 +++--
>>  7 files changed, 24 insertions(+), 13 deletions(-)
> [cut]
>
>> diff --git a/meta/classes/useradd_base.bbclass
>> b/meta/classes/useradd_base.bbclass
>> index f4dc713..35d5f06 100644
>> --- a/meta/classes/useradd_base.bbclass
>> +++ b/meta/classes/useradd_base.bbclass
>> @@ -59,10 +59,10 @@ perform_groupmems () {
>>  gshadow="no"
>>  touch $rootdir${sysconfdir}/gshadow
>>  fi
>> -local mem_exists="`grep 
>> "^$groupname:[^:]*:[^:]*:\([^,]*,\)*$username\(,[^,]*\)*"$rootdir/etc/group 
>> || true`"
>> +local mem_exists="`grep 
>> "^$groupname:[!:]*:[!:]*:\([!,]*,\)*$username\(,[!,]*\)*"$rootdir/etc/group 
>> || true`"
>>  if test "x$mem_exists" = "x"; then
>>  eval flock -x $rootdir${sysconfdir} -c \"$PSEUDO groupmems 
>> \$opts\" || true
>> -mem_exists="`grep 
>> "^$groupname:[^:]*:[^:]*:\([^,]*,\)*$username\(,[^,]*\)*"$rootdir/etc/group 
>> || true`"
>> ++   mem_exists="`grep 
>> "^$groupname:[!:]*:[!:]*:\([!,]*,\)*$username\(,[!,]*\)*"$rootdir/etc/group 
>> || true`"
>>  if test "x$mem_exists" = "x"; then
>>  bbfatal "${PN}: groupmems command did not succeed."
>>  fi
> The above change cannot be correct. Changing the expression "[^:]" 
> (which means "anything but :") to "[!:]" (which means "! or :") is 
> definitely not the same

Thanks for careful review. I really missed correcting thisfalse-positive report.

>> diff --git a/meta/recipes-devtools/guile/guile_2.0.12.bb
>> b/meta/recipes-devtools/guile/guile_2.0.12.bb
>> index d2fe511..3ada0f1 100644
>> --- a/meta/recipes-devtools/guile/guile_2.0.12.bb
>> +++ b/meta/recipes-devtools/guile/guile_2.0.12.bb
>> @@ -91,8 +91,10 @@ guile_cross_config() {
>>  then
>>  # Create guile-config returning target values instead of native 
>> values
>>  install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
>> -echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e 
>> main -s\n!#\n(define %guile-build-info '\'\( \
>> -> ${B}/guile-config.cross
>> +echo -n '#!' > ${B}/guile-config.cross
>> +echo -n `which x86_64-linux-guile` >> ${B}/guile-config.cross
>> +printf ' \\\n--no-auto-compile -e main -s\n!#\n(define 
>> %%guile-build-info ' >> ${B}/guile-config.cross
>> +echo "'(" >> ${B}/guile-config.cross
>>  sed -n -e 's:^[ \t]*{[ \t]*":  (:' \
>>  -e 's:",[ \t]*": . ":' \
>>  -e 's:" *}, *\\:"):' \
> I suggest to replace the entire guile_cross_config() function with this:
>
> guile_cross_config() {
>   # this is only for target recipe
>   [ "${PN}" = "${BPN}" ] || return 0
>
>   vars=$(sed -n -e 's:^[ \t]*{[ \t]*":  (:' \
> -e 's:",[ \t]*": . ":' \
> -e 's:" *}, *\\:"):' \
> -e 's:^.*cachedir.*$::&#

Re: [OE-core] [PATCH] bash2dash conversion

2016-09-22 Thread He Zhe



On 09/19/2016 08:07 PM, Burton, Ross wrote:
>
> On 19 September 2016 at 12:57, Peter Kjellerstedt 
> mailto:peter.kjellerst...@axis.com>>wrote:
>
> > ++mem_exists="`grep 
> "^$groupname:[!:]*:[!:]*:\([!,]*,\)*$username\(,[!,]*\)*"$rootdir/etc/group 
> || true`"
> >   if test "x$mem_exists" = "x"; then
> >   bbfatal "${PN}: groupmems command did not 
> succeed."
> >   fi
>
> The above change cannot be correct. Changing the expression "[^:]"
> (which means "anything but :") to "[!:]" (which means "! or :") is
> definitely not the same
>
>
> My prediction is that this series is generated by running checkbashism over 
> the fragments, it fires a false-positive here (from memory because it thinks 
> it is processing a bash glob or something, not grep regex).
>
> Note that I just submitted my verify-bashism script which has a whitelist for 
> things - such as use of command - which whilst not in POSIX are in fact in 
> bash/dash/ash so for all intents and purposes will work.
>

Yes, I'm using checkbashism and have found some false-positive reports but 
missed this one. Thank you for pointing out.

Zhe

> Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Remove bashisms

2016-09-25 Thread He Zhe

OK. I have senta new patch([OE-core] [PATCH] guile: Remove bashisms) for guile 
as other bashisms have been addressed.

Thanks,
Zhe

On 09/22/2016 06:04 PM, Burton, Ross wrote:
> On 22 September 2016 at 10:33,  >wrote:
>
> -if type systemctl >/dev/null 2>/dev/null; then
> +if command -p systemctl >/dev/null 2>/dev/null; then
>
>
> This doesn't do what you want:
>
> $ type whoami ; echo $?
> whoami is /usr/bin/whoami
> 0
> $ type foobar; echo $?
> -bash: type: foobar: not found
> 1
>
> 'type' when used with a binary prints the full path (thus the redirect) and 
> returns success if it was found, error if it wasn't.
>
> $ command -p whoami ; echo $?
> ross
> 0
>
> $ which applyotron
> /home/ross/bin/applyotron
> $ command -p applyotron
> -bash: applyotron: command not found
>
> 'command -p' searches for a binary (ignoring any aliases or builtins) in a 
> hardcoded set of paths as you pass -p (not $PATH, so will fail at rootfs 
> time) for a binary and executes it if found.  We don't want to look in a 
> hard-coded set of paths, and we don't want to run the binary, so these 
> changes are bad.
>
> bash, dash and ash all support type, which is why verify-bashisms has them on 
> the whitelist as the simplest way of saying "does this binary exist".
>
>
> # Remove unpackaged files (based on list in rpm.spec)
> -   rm -f 
> ${D}/${libdir}/rpm/{Specfile.pm,cpanflute,cpanflute2,rpmdiff,rpmdiff.cgi,sql.prov,sql.req,tcl.req,trpm}
> +   rm -f ${D}/${libdir}/rpm/Specfile.pm
> +   rm -f ${D}/${libdir}/rpm/cpanflute
> +   rm -f ${D}/${libdir}/rpm/cpanflute2
> +   rm -f ${D}/${libdir}/rpm/rpmdiff
> +   rm -f ${D}/${libdir}/rpm/rpmdiff.cgi
> +   rm -f ${D}/${libdir}/rpm/sql.prov
> +   rm -f ${D}/${libdir}/rpm/sql.req
> +   rm -f ${D}/${libdir}/rpm/tcl.req
> +   rm -f ${D}/${libdir}/rpm/trpm
>
>
> I deleted these in "rpm: remove redundant removals" when doing a similar 
> sweep, so please rebase to master.
>
> I think all thats left is the guile cleanup, so can you submit just that with 
> a rewritten commit message.
>
> Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] Remove bashisms

2016-09-29 Thread He Zhe

Sorry for slow reply.

This is probably caused by the correction of installation path(from 
${STAGING_BINDIR_CROSS}/guile-config to 
${SYSROOT_DESTDIR}${bindir_crossscripts}/guile-config). do_populate_sysroot 
helps us install things into ${STAGING_BINDIR_CROSS}/guile-config, we shouldn't 
do that ourselves. But if we do that and then apply this patch and then 
rebuild, the system will find they have existed and also find no one installed 
them(Matched in b''). So this should be a wrong report. This error will not 
appear if I manually delete guile-config and rebuild or rebuild in a brand new 
project.

I sent a new one([oe] [meta-oe] [PATCH] Remove bashisms) in 09/27/2016 02:19 
PM. Please apply that one if it's OK.

Thanks,
Zhe


On 09/27/2016 09:43 PM, Burton, Ross wrote:
> If I apply this and then re-build guile I get this error:
>
> ERROR: guile-2.0.12-r0 do_populate_sysroot: The recipe guile is trying to 
> install files into a shared area when those files already exist. Those files 
> and their manifest location are:
>
> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/bin/crossscripts/guile-config
>  Matched in b''
>
> Ross
>
> On 22 September 2016 at 10:33,  <mailto:zhe...@windriver.com>>wrote:
>
> From: "Tim K. Chan" mailto:nirvan...@gmail.com>>
>
> Signed-off-by: Tim K. Chan  <mailto:nirvan...@gmail.com>>
>     [
> Adjust context
> Use Peter Kjellerstedt's simpler guile_cross_config
> ]
> Signed-off-by: He Zhe mailto:zhe...@windriver.com>>
> ---
>  meta/classes/systemd.bbclass   |  4 +--
>  meta/classes/update-rc.d.bbclass   |  6 ++--
>  .../resolvconf/resolvconf_1.79.bb <http://resolvconf_1.79.bb>
>   |  2 +-
>  meta/recipes-core/glibc/glibc-package.inc  |  2 +-
>  meta/recipes-devtools/guile/guile_2.0.12.bb <http://guile_2.0.12.bb> 
>| 37 --
>  meta/recipes-devtools/rpm/rpm_5.4.16.bb <http://rpm_5.4.16.bb>   
>  | 13 ++--
>  6 files changed, 39 insertions(+), 25 deletions(-)
>
> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> index db7873f..7370489 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -28,7 +28,7 @@ if [ -n "$D" ]; then
>  OPTS="--root=$D"
>  fi
>
> -if type systemctl >/dev/null 2>/dev/null; then
> +if command -p systemctl >/dev/null 2>/dev/null; then
> systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>
> if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> @@ -44,7 +44,7 @@ if [ -n "$D" ]; then
>  OPTS="--root=$D"
>  fi
>
> -if type systemctl >/dev/null 2>/dev/null; then
> +if command -p systemctl >/dev/null 2>/dev/null; then
> if [ -z "$D" ]; then
> systemctl stop ${SYSTEMD_SERVICE}
> fi
> diff --git a/meta/classes/update-rc.d.bbclass 
> b/meta/classes/update-rc.d.bbclass
> index 82b8024..dee80c8 100644
> --- a/meta/classes/update-rc.d.bbclass
> +++ b/meta/classes/update-rc.d.bbclass
> @@ -15,7 +15,7 @@ updatercd_preinst() {
>  if [ -z "$D" -a -f "${INIT_D_DIR}/${INITSCRIPT_NAME}" ]; then
> ${INIT_D_DIR}/${INITSCRIPT_NAME} stop
>  fi
> -if type update-rc.d >/dev/null 2>/dev/null; then
> +if command -p update-rc.d >/dev/null 2>/dev/null; then
> if [ -n "$D" ]; then
> OPT="-f -r $D"
> else
> @@ -26,7 +26,7 @@ fi
>  }
>
>  updatercd_postinst() {
> -if type update-rc.d >/dev/null 2>/dev/null; then
> +if command -p update-rc.d >/dev/null 2>/dev/null; then
> if [ -n "$D" ]; then
> OPT="-r $D"
> else
> @@ -43,7 +43,7 @@ fi
>  }
>
>  updatercd_postrm() {
> -if type update-rc.d >/dev/null 2>/dev/null; then
> +if command -p update-rc.d >/dev/null 2>/dev/null; then
> if [ -n "$D" ]; then
> OPT="-f -r $D"
> else
> diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.79.bb 
> <http://resolvconf_1.79.bb>b/meta/recipes-connectivity/resolvconf/resolvconf_1.79.bb
>  <http://resolvconf_1.79.bb>
> index 8550177..e415445 100644
> --- a/meta/recipes-connectivity/resolvconf/resolvconf_1.79.bb 
>

Re: [OE-core] [PATCH] guile: Remove bashisms

2016-10-08 Thread He Zhe

Hi Ross,

This one is the latest version for previously reviewed "[OE-core] [PATCH v2] 
Remove bashisms", but I forgot mentioning it.

Thanks,
Zhe

On 09/26/2016 02:51 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> Remove bashisms from do_populate_sysroot task
>
> Signed-off-by: Peter Kjellerstedt 
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-devtools/guile/guile_2.0.12.bb | 29 
> +
>  1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/meta/recipes-devtools/guile/guile_2.0.12.bb 
> b/meta/recipes-devtools/guile/guile_2.0.12.bb
> index d2fe511..751a035 100644
> --- a/meta/recipes-devtools/guile/guile_2.0.12.bb
> +++ b/meta/recipes-devtools/guile/guile_2.0.12.bb
> @@ -87,22 +87,27 @@ SYSROOT_PREPROCESS_FUNCS = "guile_cross_config"
>  
>  guile_cross_config() {
>   # this is only for target recipe
> - if [ "${PN}" = "guile" ]
> - then
> - # Create guile-config returning target values instead of native 
> values
> - install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
> - echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e 
> main -s\n!#\n(define %guile-build-info '\'\( \
> - > ${B}/guile-config.cross
> - sed -n -e 's:^[ \t]*{[ \t]*":  (:' \
> + [ "${PN}" = "${BPN}" ] || return 0
> +
> + vars=$(sed -n -e 's:^[ \t]*{[ \t]*":  (:' \
>   -e 's:",[ \t]*": . ":' \
>   -e 's:" *}, *\\:"):' \
>   -e 's:^.*cachedir.*$::' \
>   -e '/^  (/p' \
> - < ${B}/libguile/libpath.h >> ${B}/guile-config.cross
> - echo '))' >> ${B}/guile-config.cross
> - cat ${B}/meta/guile-config >> ${B}/guile-config.cross
> - install ${B}/guile-config.cross 
> ${STAGING_BINDIR_CROSS}/guile-config
> - fi
> + < ${B}/libguile/libpath.h)
> +
> + # Create guile-config returning target values instead of native values
> + install -d ${SYSROOT_DESTDIR}${bindir_crossscripts}
> + cat <${B}/guile-config.cross
> +#!$(which ${BUILD_SYS}-guile) \\
> +--no-auto-compile -e main -s
> +!#
> +(define %guile-build-info '(
> +$vars
> +))
> +EOF
> + cat ${B}/meta/guile-config >> ${B}/guile-config.cross
> + install ${B}/guile-config.cross 
> ${SYSROOT_DESTDIR}${bindir_crossscripts}/guile-config
>  }
>  
>  # Guile needs the compiled files to be newer than the source, and it won't

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] guile: Remove bashisms

2016-10-11 Thread He Zhe

Thanks for pointing out.

This seems caused by the correction of installation path of guile-config(from 
${STAGING_BINDIR_CROSS} to ${SYSROOT_DESTDIR}${bindir_crossscripts}). We first 
put things in ${SYSROOT_DESTDIR}. And then do_populate_sysroot collects them 
from ${SYSROOT_DESTDIR} and install them into ${STAGING_BINDIR_CROSS}. But if 
we first put guile-configin ${STAGING_BINDIR_CROSS}, as we did before, and then 
apply this patch and then rebuild, the system will find guile-confighas existed 
in ${STAGING_BINDIR_CROSS} but cannot find who installed it(Matched in b''). So 
this is probably a wrong report. This error will not appear if I manually 
delete ${STAGING_BINDIR_CROSS}/guile-config and rebuild, or rebuild in a brand 
new project.

Zhe

On 10/10/2016 09:15 PM, Burton, Ross wrote:
>
> On 26 September 2016 at 07:51,  >wrote:
>
> Remove bashisms from do_populate_sysroot task
>
>
> This causes a change of behaviour that results in a stage error:
>
> ERROR: guile-2.0.12-r0 do_populate_sysroot: The recipe guile is trying to 
> install files into a shared area when those files already exist. Those files 
> and their manifest location are:
>
> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/bin/crossscripts/guile-config
>  Matched in b''
> Please verify which recipe should provide the above files.
>
> Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-yocto/4.12: integrate CGL features support

2017-10-10 Thread He Zhe

The CGL features now have a 4.12 port, so we can integrate them into
the reference kernel.

Signed-off-by: He Zhe 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.12.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb
index c49a934..faf82ed 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_meta ?= "eda4d18ce4b259c84ccd5c249c3dc5958c16928c"
+SRCREV_meta ?= "73365069d89a8423a6f9f4b5560ee6bfdfc0b3d1"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.12.git;branch=${KBRANCH};name=machine 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb
index ba67af3..efad337 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_meta ?= "eda4d18ce4b259c84ccd5c249c3dc5958c16928c"
+SRCREV_meta ?= "73365069d89a8423a6f9f4b5560ee6bfdfc0b3d1"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.12.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.12.bb
index a262409..c9449e2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.12.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.12.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"16de0149674ed12d983b77a453852ac2e64584b4"
 SRCREV_machine_qemux86-64 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
 SRCREV_machine_qemumips64 ?= "9d63d9c11c44ceabd452d7ee49cf55a88c39383f"
 SRCREV_machine ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_meta ?= "eda4d18ce4b259c84ccd5c249c3dc5958c16928c"
+SRCREV_meta ?= "73365069d89a8423a6f9f4b5560ee6bfdfc0b3d1"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH};
 \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
-- 
2.10.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-libc-headers: Fix build failure by using fixed input and output files instead of pipe

2018-12-24 Thread He Zhe

This is an amendment for
2322dc4 "linux-libc-headers: Fix build failure by using fixed temporary file 
instead of pipe"
which moves just the temporary input file from /tmp to build directory. But the
build directory may not in the same file system with the output file,
/dev/null, either and thus make it possible to trigger that bug, 67f846b, in
binutil v2.31.

This patch puts both the input and output files into build directory for good.

Signed-off-by: He Zhe 
---
 ...fixed-input-and-output-files-instead-of-.patch} | 22 ++
 .../linux-libc-headers/linux-libc-headers_4.18.bb  |  2 +-
 2 files changed, 11 insertions(+), 13 deletions(-)
 rename 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/{0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
 => 0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch} (83%)

diff --git 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
similarity index 83%
rename from 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
rename to 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
index 0d8fa80939..9ba1c076e8 100644
--- 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
+++ 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
@@ -1,7 +1,7 @@
-From 3bbea65e11918f8753e8006a2198b999cdb0af58 Mon Sep 17 00:00:00 2001
+From 694eba7bb974f6b8bd308804cb24350150108b2b Mon Sep 17 00:00:00 2001
 From: He Zhe 
 Date: Wed, 21 Nov 2018 15:12:43 +0800
-Subject: [PATCH] scripts: Use fixed temporary file instead of pipe for
+Subject: [PATCH] scripts: Use fixed input and output files instead of pipe for
  here-doc
 
 There was a bug of "as" in binutils that when it checks if the input file and
@@ -40,31 +40,29 @@ Upstream-Status: Inappropriate [A work around for binutils 
v2.31]
 
 Signed-off-by: He Zhe 
 ---
- scripts/gcc-goto.sh | 7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
+ scripts/gcc-goto.sh | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
-index 083c526..0aaf1b4 100755
+index 083c526..8dfac55 100755
 --- a/scripts/gcc-goto.sh
 +++ b/scripts/gcc-goto.sh
-@@ -3,7 +3,9 @@
+@@ -3,7 +3,7 @@
  # Test for gcc 'asm goto' support
  # Copyright (C) 2010, Jason Baron 
  
 -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
-+TMPFILE=`mktemp -p .`
-+
-+cat << "END" > ${TMPFILE}
++cat << "END" > ./input
  int main(void)
  {
  #if defined(__arm__) || defined(__aarch64__)
-@@ -20,3 +22,6 @@ entry:
+@@ -20,3 +20,6 @@ entry:
return 0;
  }
  END
 +
-+$@ -x c ${TMPFILE} -c -o /dev/null && echo "y"
-+rm ${TMPFILE}
++$@ -x c ./input -c -o ./output && echo "y"
++rm ./input ./output
 -- 
 2.7.4
 
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
index 00420aa6f7..229a0027d7 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
@@ -10,7 +10,7 @@ SRC_URI_append_libc-musl = "\
"
 
 SRC_URI_append = "\
-file://0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch \
+file://0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch \
 "
 
 SRC_URI[md5sum] = "bee5fe53ee1c3142b8f0c12c0d3348f9"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-libc-headers: Fix build failure with fixed input and output files instead of pipe

2018-12-25 Thread He Zhe

This is an amendment for
2322dc4 "linux-libc-headers: Fix build failure by using fixed temporary file 
instead of pipe"
which moves just the temporary input file from /tmp to build directory. But the
build directory may not in the same file system with the output file,
/dev/null, either and thus make it possible to trigger that bug, 67f846b, in
binutil v2.31.

This patch puts both the input and output files into build directory for good.

Signed-off-by: He Zhe 
---
 ...fixed-input-and-output-files-instead-of-.patch} | 22 ++
 .../linux-libc-headers/linux-libc-headers_4.18.bb  |  2 +-
 2 files changed, 11 insertions(+), 13 deletions(-)
 rename 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/{0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
 => 0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch} (83%)

diff --git 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
similarity index 83%
rename from 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
rename to 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
index 0d8fa80939..9ba1c076e8 100644
--- 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch
+++ 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch
@@ -1,7 +1,7 @@
-From 3bbea65e11918f8753e8006a2198b999cdb0af58 Mon Sep 17 00:00:00 2001
+From 694eba7bb974f6b8bd308804cb24350150108b2b Mon Sep 17 00:00:00 2001
 From: He Zhe 
 Date: Wed, 21 Nov 2018 15:12:43 +0800
-Subject: [PATCH] scripts: Use fixed temporary file instead of pipe for
+Subject: [PATCH] scripts: Use fixed input and output files instead of pipe for
  here-doc
 
 There was a bug of "as" in binutils that when it checks if the input file and
@@ -40,31 +40,29 @@ Upstream-Status: Inappropriate [A work around for binutils 
v2.31]
 
 Signed-off-by: He Zhe 
 ---
- scripts/gcc-goto.sh | 7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
+ scripts/gcc-goto.sh | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/scripts/gcc-goto.sh b/scripts/gcc-goto.sh
-index 083c526..0aaf1b4 100755
+index 083c526..8dfac55 100755
 --- a/scripts/gcc-goto.sh
 +++ b/scripts/gcc-goto.sh
-@@ -3,7 +3,9 @@
+@@ -3,7 +3,7 @@
  # Test for gcc 'asm goto' support
  # Copyright (C) 2010, Jason Baron 
  
 -cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
-+TMPFILE=`mktemp -p .`
-+
-+cat << "END" > ${TMPFILE}
++cat << "END" > ./input
  int main(void)
  {
  #if defined(__arm__) || defined(__aarch64__)
-@@ -20,3 +22,6 @@ entry:
+@@ -20,3 +20,6 @@ entry:
return 0;
  }
  END
 +
-+$@ -x c ${TMPFILE} -c -o /dev/null && echo "y"
-+rm ${TMPFILE}
++$@ -x c ./input -c -o ./output && echo "y"
++rm ./input ./output
 -- 
 2.7.4
 
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
index 00420aa6f7..229a0027d7 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.18.bb
@@ -10,7 +10,7 @@ SRC_URI_append_libc-musl = "\
"
 
 SRC_URI_append = "\
-file://0001-scripts-Use-fixed-temporary-file-instead-of-pipe-for.patch \
+file://0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch \
 "
 
 SRC_URI[md5sum] = "bee5fe53ee1c3142b8f0c12c0d3348f9"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ltp: Remove admin_tools test

2019-01-13 Thread He Zhe

admin_tools test group has been removed from upstream. Backport to fix the
following failures.

at_deny01 1 TFAIL : ltpapicmd.c:188: At denyed user to execute test job
at_allow01 1 TFAIL : ltpapicmd.c:188: At did not allow user to execute job

Signed-off-by: He Zhe 
---
 .../ltp/ltp/0001-Remove-admin_tools-test.patch | 3037 
 meta/recipes-extended/ltp/ltp_20180926.bb  |1 +
 2 files changed, 3038 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch

diff --git a/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch 
b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
new file mode 100644
index 00..b740f22355
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
@@ -0,0 +1,3037 @@
+From 0fc9b8624bea8acfdb408bf5ff4916b1453e3daa Mon Sep 17 00:00:00 2001
+From: Petr Vorel 
+Date: Thu, 27 Sep 2018 16:57:20 +0200
+Subject: [PATCH] Remove admin_tools test
+
+Removing cron, at, su related tests as they don't really fit into
+"kernel testing", it'd be better to have them in some "LTP userspace"
+project.
+ACL are considered as "kernel tests", but it would be easier to write
+something from scratch, thus remove them as well.
+
+Signed-off-by: Petr Vorel 
+Acked-by: Xiao Yang 
+Acked-by: Jan Stancek 
+Acked-by: Cyril Hrubis 
+-#   Copyright (c) International Business Machines  Corp., 2003
+-#
+-#   This program is free software; you can redistribute it and/or modify
+-#   it under the terms of the GNU General Public License as published by
+-#   the Free Software Foundation; either version 2 of the License, or
+-#   (at your option) any later version.
+-#
+-#   This program is distributed in the hope that it will be useful, but
+-#   WITHOUT ANY WARRANTY; without even the implied warranty of
+-#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+-#   General Public License for more details.
+-#
+-#   You should have received a copy of the GNU General Public License
+-#   along with this program; if not, write to the Free Software
+-#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+-#   USA
+-#
+-#   FILE: /etc/at.allow
+-#
+-#   PURPOSE: Test that /etc/at.allow , only allows those in the file to
+-#   run cron jobs.
+-#
+-#   HISTORY:
+-#04/03 Jerone Young (jyou...@us.ibm.com)
+-#
+-
+-export TCID=at_allow01
+-export TST_TOTAL=1
+-export TST_COUNT=1
+-TMP=${TMP:=/tmp}
+-allow="/etc/at.allow"
+-test_user1="test_user_1"
+-test_user2="test_user_2"
+-test_user1_home="/home/${test_user1}"
+-test_user2_home="/home/${test_user2}"
+-tmpfile="$TMP/at_allow_test"
+-
+-if [ "$(id -ru)" = 0 ]; then
+-  . cmdlib.sh
+-fi
+-
+-#---
+-# FUNCTION:  do_setup
+-#---
+-
+-do_setup()
+-{
+-  # Move any files that may get in the way.
+-  rm "${tmpfile}" >/dev/null 2>&1
+-  mv "${allow}" "${allow}.old" >/dev/null 2>&1
+-
+-  # Remove users for clean enviroment.
+-  rm -rf "${test_user1_home}" "${test_user2_home}"
+-  userdel -r "${test_user1}" >/dev/null 2>&1
+-  userdel -r "${test_user2}" >/dev/null 2>&1
+-
+-  # Create the 1st user.
+-  if ! useradd -g users -d "${test_user1_home}" -m "${test_user1}"; then
+-  echo "Could not add test user ${test_user1} to system."
+-  exit 1
+-  fi
+-
+-  # Create the 2nd user.
+-  if ! useradd -g users -d "${test_user2_home}" -m "${test_user2}"; then
+-  echo "Could not add test user ${test_user2} to system."
+-  exit 1
+-  fi
+-
+-  # This is the workaround for a potential bug.
+-  # [Bug 468337] At Refuse to Work with Non-login Shell
+-  # https://bugzilla.redhat.com/show_bug.cgi?id=468337
+-  # As we are running in non-login shell now, we cannot run the script
+-  # by simply given it a relative path. Therefore, we copy it to test
+-  # users' home directories, and run it from there.
+-  cp "$0" "${test_user1_home}/." &&
+-  cp "$0" "${test_user2_home}/." &&
+-  echo "export LTPROOT='$LTPROOT'" > "${test_user1_home}/cached_ltproot" 
&&
+-  echo "export LTPROOT='$LTPROOT'" > "${test_user2_home}/cached_ltproot"
+-  if [ $? -ne 0 ]; then
+-  tst_resm TBROK "Couldn't copy over req'd files for test users"
+-  exit 1
+-  fi
+-
+-  restart_daemon atd
+-}
+-
+-#--

[OE-core] [PATCH v2] ltp: Remove admin_tools test

2019-01-14 Thread He Zhe

admin_tools test group has been removed from upstream. Backport to fix the
following failures.

at_deny01 1 TFAIL : ltpapicmd.c:188: At denyed user to execute test job
at_allow01 1 TFAIL : ltpapicmd.c:188: At did not allow user to execute job

Signed-off-by: He Zhe 
---
v2: Add missing SOB and upstream status.

 .../ltp/ltp/0001-Remove-admin_tools-test.patch | 3042 
 meta/recipes-extended/ltp/ltp_20180926.bb  |1 +
 2 files changed, 3043 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch

diff --git a/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch 
b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
new file mode 100644
index 00..2fc5be82a1
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
@@ -0,0 +1,3042 @@
+From 0fc9b8624bea8acfdb408bf5ff4916b1453e3daa Mon Sep 17 00:00:00 2001
+From: Petr Vorel 
+Date: Thu, 27 Sep 2018 16:57:20 +0200
+Subject: [PATCH] Remove admin_tools test
+
+Removing cron, at, su related tests as they don't really fit into
+"kernel testing", it'd be better to have them in some "LTP userspace"
+project.
+ACL are considered as "kernel tests", but it would be easier to write
+something from scratch, thus remove them as well.
+
+Signed-off-by: Petr Vorel 
+Acked-by: Xiao Yang 
+Acked-by: Jan Stancek 
+Acked-by: Cyril Hrubis https://github.com/linux-test-project/ltp/commit/0fc9b8624bea8acfdb408bf5ff4916b1453e3daa]
+
+Signed-off-by: He Zhe 
+
+---
+ runtest/admin_tools |   9 -
+ runtest/commands|   1 -
+ scenario_groups/default |   1 -
+ testcases/commands/.gitignore   |   1 -
+ testcases/commands/at/Makefile  |  31 --
+ testcases/commands/at/at_allow01| 188 -
+ testcases/commands/at/at_deny01 | 195 --
+ testcases/commands/cron/00_Descriptions.txt |   4 -
+ testcases/commands/cron/Makefile|  29 --
+ testcases/commands/cron/README.tests|  25 --
+ testcases/commands/cron/cron02  |  80 
+ testcases/commands/cron/cron03  |  83 
+ testcases/commands/cron/cron_allow01| 202 --
+ testcases/commands/cron/cron_deny01 | 192 --
+ testcases/commands/cron/cron_dirs_check.c   |  44 ---
+ testcases/commands/cron/cron_dirs_checks01  |  46 ---
+ testcases/commands/cron/cron_illegal_cron_lines |  39 --
+ testcases/commands/cron/cron_neg_tests.sh   | 141 ---
+ testcases/commands/cron/cron_pos_tests.sh   | 118 --
+ testcases/commands/cron/cron_tests.sh   | 276 --
+ testcases/commands/su/Makefile  |  31 --
+ testcases/commands/su/su01  | 181 -
+ testcases/commands/su/su01_s1   | 486 
+ testcases/commands/su/su_set_passwd |  14 -
+ testcases/kernel/fs/acls/.gitignore |   2 -
+ testcases/kernel/fs/acls/Makefile   |  40 --
+ testcases/kernel/fs/acls/acl_file_test.c|  73 
+ testcases/kernel/fs/acls/acl_link_test.c|  56 ---
+ testcases/kernel/fs/acls/acl_test01 | 186 -
+ 29 files changed, 2774 deletions(-)
+ delete mode 100644 runtest/admin_tools
+ delete mode 100644 testcases/commands/at/Makefile
+ delete mode 100755 testcases/commands/at/at_allow01
+ delete mode 100755 testcases/commands/at/at_deny01
+ delete mode 100644 testcases/commands/cron/00_Descriptions.txt
+ delete mode 100644 testcases/commands/cron/Makefile
+ delete mode 100644 testcases/commands/cron/README.tests
+ delete mode 100755 testcases/commands/cron/cron02
+ delete mode 100755 testcases/commands/cron/cron03
+ delete mode 100755 testcases/commands/cron/cron_allow01
+ delete mode 100755 testcases/commands/cron/cron_deny01
+ delete mode 100644 testcases/commands/cron/cron_dirs_check.c
+ delete mode 100755 testcases/commands/cron/cron_dirs_checks01
+ delete mode 100644 testcases/commands/cron/cron_illegal_cron_lines
+ delete mode 100755 testcases/commands/cron/cron_neg_tests.sh
+ delete mode 100755 testcases/commands/cron/cron_pos_tests.sh
+ delete mode 100644 testcases/commands/cron/cron_tests.sh
+ delete mode 100644 testcases/commands/su/Makefile
+ delete mode 100755 testcases/commands/su/su01
+ delete mode 100755 testcases/commands/su/su01_s1
+ delete mode 100755 testcases/commands/su/su_set_passwd
+ delete mode 100644 testcases/kernel/fs/acls/.gitignore
+ delete mode 100644 testcases/kernel/fs/acls/Makefile
+ delete mode 100644 testcases/kernel/fs/acls/acl_file_test.c
+ delete mode 100644 testcases/kernel/fs/acls/acl_link_test.c
+ delete mode 100755 testcases/kernel/fs/acls/acl_test01
+
+diff --git a/runtest/admin_tools b/runtest/admin_tools
+deleted file mode 100644
+i

Re: [OE-core] [PATCH v2] ltp: Remove admin_tools test

2019-01-28 Thread He Zhe

Kindly ping.

Zhe

On 1/15/19 10:47 AM, He Zhe wrote:
> admin_tools test group has been removed from upstream. Backport to fix the
> following failures.
>
> at_deny01 1 TFAIL : ltpapicmd.c:188: At denyed user to execute test job
> at_allow01 1 TFAIL : ltpapicmd.c:188: At did not allow user to execute job
>
> Signed-off-by: He Zhe 
> ---
> v2: Add missing SOB and upstream status.
>
>  .../ltp/ltp/0001-Remove-admin_tools-test.patch | 3042 
> 
>  meta/recipes-extended/ltp/ltp_20180926.bb  |1 +
>  2 files changed, 3043 insertions(+)
>  create mode 100644 
> meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
>
> diff --git a/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch 
> b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
> new file mode 100644
> index 00..2fc5be82a1
> --- /dev/null
> +++ b/meta/recipes-extended/ltp/ltp/0001-Remove-admin_tools-test.patch
> @@ -0,0 +1,3042 @@
> +From 0fc9b8624bea8acfdb408bf5ff4916b1453e3daa Mon Sep 17 00:00:00 2001
> +From: Petr Vorel 
> +Date: Thu, 27 Sep 2018 16:57:20 +0200
> +Subject: [PATCH] Remove admin_tools test
> +
> +Removing cron, at, su related tests as they don't really fit into
> +"kernel testing", it'd be better to have them in some "LTP userspace"
> +project.
> +ACL are considered as "kernel tests", but it would be easier to write
> +something from scratch, thus remove them as well.
> +
> +Signed-off-by: Petr Vorel 
> +Acked-by: Xiao Yang 
> +Acked-by: Jan Stancek 
> +Acked-by: Cyril Hrubis  +
> +Upstream-Status: Backport 
> [https://github.com/linux-test-project/ltp/commit/0fc9b8624bea8acfdb408bf5ff4916b1453e3daa]
> +
> +Signed-off-by: He Zhe 
> +
> +---
> + runtest/admin_tools |   9 -
> + runtest/commands|   1 -
> + scenario_groups/default |   1 -
> + testcases/commands/.gitignore   |   1 -
> + testcases/commands/at/Makefile  |  31 --
> + testcases/commands/at/at_allow01| 188 -
> + testcases/commands/at/at_deny01 | 195 --
> + testcases/commands/cron/00_Descriptions.txt |   4 -
> + testcases/commands/cron/Makefile|  29 --
> + testcases/commands/cron/README.tests|  25 --
> + testcases/commands/cron/cron02  |  80 
> + testcases/commands/cron/cron03  |  83 
> + testcases/commands/cron/cron_allow01| 202 --
> + testcases/commands/cron/cron_deny01 | 192 --
> + testcases/commands/cron/cron_dirs_check.c   |  44 ---
> + testcases/commands/cron/cron_dirs_checks01  |  46 ---
> + testcases/commands/cron/cron_illegal_cron_lines |  39 --
> + testcases/commands/cron/cron_neg_tests.sh   | 141 ---
> + testcases/commands/cron/cron_pos_tests.sh   | 118 --
> + testcases/commands/cron/cron_tests.sh   | 276 --
> + testcases/commands/su/Makefile  |  31 --
> + testcases/commands/su/su01  | 181 -
> + testcases/commands/su/su01_s1   | 486 
> 
> + testcases/commands/su/su_set_passwd |  14 -
> + testcases/kernel/fs/acls/.gitignore |   2 -
> + testcases/kernel/fs/acls/Makefile   |  40 --
> + testcases/kernel/fs/acls/acl_file_test.c|  73 
> + testcases/kernel/fs/acls/acl_link_test.c|  56 ---
> + testcases/kernel/fs/acls/acl_test01 | 186 -
> + 29 files changed, 2774 deletions(-)
> + delete mode 100644 runtest/admin_tools
> + delete mode 100644 testcases/commands/at/Makefile
> + delete mode 100755 testcases/commands/at/at_allow01
> + delete mode 100755 testcases/commands/at/at_deny01
> + delete mode 100644 testcases/commands/cron/00_Descriptions.txt
> + delete mode 100644 testcases/commands/cron/Makefile
> + delete mode 100644 testcases/commands/cron/README.tests
> + delete mode 100755 testcases/commands/cron/cron02
> + delete mode 100755 testcases/commands/cron/cron03
> + delete mode 100755 testcases/commands/cron/cron_allow01
> + delete mode 100755 testcases/commands/cron/cron_deny01
> + delete mode 100644 testcases/commands/cron/cron_dirs_check.c
> + delete mode 100755 testcases/commands/cron/cron_dirs_checks01
> + delete mode 100644 testcases/commands/cron/cron_illegal_cron_lines
> + delete mode 100755 testcases/commands/cron/cron_neg_tests.sh
> + delete mode 100755 testcases/commands/cron/cron_pos_tests.sh
> + delete mode 100644 testcases/commands/cron/cron_tests.sh
> + delete mode 100644 testcases/commands/

Re: [OE-core] [PATCH v2] ltp: Remove admin_tools test

2019-01-29 Thread He Zhe




On 1/28/19 10:09 PM, Richard Purdie wrote:
> On Mon, 2019-01-14 at 18:47 -0800, He Zhe wrote:
>> admin_tools test group has been removed from upstream. Backport to
>> fix the
>> following failures.
>>
>> at_deny01 1 TFAIL : ltpapicmd.c:188: At denyed user to execute test
>> job
>> at_allow01 1 TFAIL : ltpapicmd.c:188: At did not allow user to
>> execute job
>>
>> Signed-off-by: He Zhe 
>> ---
>> v2: Add missing SOB and upstream status.
> Rather than add the huge patch could we upgrade please?
>
> I believe Petr sent a patch but it had some issues so perhaps you could
> help fix those?

OK. I'll go check what I can help.

Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] ltp: nm01: Remove prefix zeros of the addresses output by nm before comparing

2020-01-06 Thread He Zhe

I saw that thread stop a few days ago. This was just merged in ltp about 10 
hours ago and should not be in that patch.

Regards,
Zhe

On 1/6/20 7:51 PM, Ross Burton wrote:
> We've a patch queued to upgrade to 20190930, is this fix included in that 
> release or does this patch need to be rebased?
>
> Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] ltp: nm01: Remove prefix zeros of the addresses output by nm before comparing

2020-01-08 Thread He Zhe

Hi Ross,

It seems that the upgrading of ltp is not moving on. And this patch is not 
included in ltp 20190930. Could we get this merged first?

Thanks,
Zhe

On 1/6/20 8:32 PM, He Zhe wrote:
> I saw that thread stop a few days ago. This was just merged in ltp about 10 
> hours ago and should not be in that patch.
>
> Regards,
> Zhe
>
> On 1/6/20 7:51 PM, Ross Burton wrote:
>> We've a patch queued to upgrade to 20190930, is this fix included in that 
>> release or does this patch need to be rebased?
>>
>> Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lttng-modules: update to 2.11.1

2020-02-02 Thread He Zhe

Oops, sure. I'll send v2.

Zhe

On 2/3/20 3:18 PM, Alexander Kanavin wrote:
> The patch files should also be removed.
>
> Alex
>
>> On 3 Feb 2020, at 7.47,   wrote:
>>
>> From: He Zhe 
>>
>> Fix build failure with kernel v5.5.
>> Remove patch as issues fixed upstream.
>>
>> Signed-off-by: He Zhe 
>> ---
>> ...modules_2.11.0.bb => lttng-modules_2.11.1.bb} | 16 ++--
>> 1 file changed, 6 insertions(+), 10 deletions(-)
>> rename meta/recipes-kernel/lttng/{lttng-modules_2.11.0.bb => 
>> lttng-modules_2.11.1.bb} (68%)
>>
>> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.0.bb 
>> b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
>> similarity index 68%
>> rename from meta/recipes-kernel/lttng/lttng-modules_2.11.0.bb
>> rename to meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
>> index 3465a43d38..c833ff7009 100644
>> --- a/meta/recipes-kernel/lttng/lttng-modules_2.11.0.bb
>> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb
>> @@ -11,14 +11,10 @@ COMPATIBLE_HOST = 
>> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
>> SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
>>file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch 
>> \
>>file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>> -   
>> file://0001-Fix-SUNRPC-Fix-oops-when-trace-sunrpc_task-events-in.patch \
>> -   
>> file://0002-Fix-sunrpc-null-rpc_clnt-dereference-in-rpc_task_que.patch \
>> -   file://0003-Fix-sunrpc-use-signed-integer-for-client-id.patch \
>> -   file://0004-sunrpc-introduce-lttng_get_clid-helper.patch \
>>"
>>
>> -SRC_URI[md5sum] = "46ec6c566e65cf27b391a1bb643e11b4"
>> -SRC_URI[sha256sum] = 
>> "98af92d8c2e00f4eb63bc637a6967103cf6997434493f36e7a535a491e4fad5f"
>> +SRC_URI[md5sum] = "0d964723c8765b39835e5e6efc60a604"
>> +SRC_URI[sha256sum] = 
>> "d3e5648937e59dee983ef844f9316c55e9961f9dc8515b9260c473bbb70696c1"
>>
>> export INSTALL_MOD_DIR="kernel/lttng-modules"
>>
>> @@ -35,13 +31,13 @@ python do_package_prepend() {
>> }
>>
>> BBCLASSEXTEND = "devupstream:target"
>> -LIC_FILES_CHKSUM_class-devupstream = 
>> "file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3"
>> +LIC_FILES_CHKSUM_class-devupstream = 
>> "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
>> DEFAULT_PREFERENCE_class-devupstream = "-1"
>> -SRC_URI_class-devupstream = 
>> "git://git.lttng.org/lttng-modules;branch=stable-2.10 \
>> +SRC_URI_class-devupstream = 
>> "git://git.lttng.org/lttng-modules;branch=stable-2.11 \
>>file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch 
>> \
>>file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>>"
>> -SRCREV_class-devupstream = "624aca5d7507fbd11ea4a1a474c3aa1031bd9a31"
>> -PV_class-devupstream = "2.10.10+git${SRCPV}"
>> +SRCREV_class-devupstream = "6ad0e68b43c3e52fcb3d47c4d823a7b84aeb443a"
>> +PV_class-devupstream = "2.11.1+git${SRCPV}"
>> S_class-devupstream = "${WORKDIR}/git"
>> SRCREV_FORMAT ?= "lttng_git"
>> -- 
>> 2.17.1
>>
>> -- 
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] perf: Correct the substitution of python shebangs

2020-02-13 Thread He Zhe

Thanks for your input.

Since the old one doesn't make it to next branch and the thread hasn't had 
following replies, I'll send v2 as a summary.

Zhe

On 2/14/20 4:45 AM, Bruce Ashfield wrote:
> On Thu, Feb 13, 2020 at 1:39 PM  wrote:
>> From: He Zhe 
>>
>> To make the native python3 are always used,
>>
>> - Move the substitution of /usr/bin/python3 to first, otherwise the
>>   possible original /usr/bin/python3 would be changed to
>>   /usr/bin/env python33.
>> - Add substitution for ${S}/scripts/
>>
>> Signed-off-by: He Zhe 
>> ---
>>  meta/recipes-kernel/perf/perf.bb | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/meta/recipes-kernel/perf/perf.bb 
>> b/meta/recipes-kernel/perf/perf.bb
>> index 6d1b066..14a9090 100644
>> --- a/meta/recipes-kernel/perf/perf.bb
>> +++ b/meta/recipes-kernel/perf/perf.bb
>> @@ -240,10 +240,17 @@ do_configure_prepend () {
>>
>>  # use /usr/bin/env instead of version specific python
>>  for s in `find ${S}/tools/perf/ -name '*.py'`; do
>> +sed -i 's,/usr/bin/python3,/usr/bin/env python3,' "${s}"
> Rather than messing around with the order of these, we should just
> combine them into a single sed invocation. When I started those
> substitutions, there weren't so many.
>
> As was mentioned in the other perf patch  and review:
>
> sed -i -e "1s,#!.*python.*,#!${USRBINPATH}/env python3," ${s}
>
> or some variant of the regex should fix them all.
>
>>  sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
>>  sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
>>  sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
>> +done
>> +
>> +for s in `find ${S}/scripts/ -name '*.py'`; do
> It would be better to not have two loops doing the same thing, why not
> combine the two ? In the other review, the single script that was
> causing the problem was specifically pointed out .. and while I also
> agree that we can just substitute them all, technically, if we haven't
> run them, we don't know they are py3 safe.
>
> But minimally, getting them into a single for loop is something we
> should do (also part of that other patch/review).
>
> Bruce
>
>>  sed -i 's,/usr/bin/python3,/usr/bin/env python3,' "${s}"
>> +sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
>> +sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
>> +sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
>>  done
>>
>>  # unistd.h can be out of sync between libc-headers and the captured 
>> version in the perf source
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] perf: Correct the substitution of python shebangs

2020-02-13 Thread He Zhe

commit log broken. Please ignore. I'll send v3.

Zhe

On 2/14/20 11:44 AM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> To make the native python3 is always used,
>
> - Move the substitution of /usr/bin/python3 to first, otherwise the
>   possible original /usr/bin/python3 would be changed to
>   /usr/bin/env python33.
> - Add substitution for ${S}/scripts/bpf_helpers_doc.py to fix the
>   following warning.
>
> File "/usr/lib/python3.6/sysconfig.py", line 421, in _init_posix
> _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
> ModuleNotFoundError: No module named '_sysconfigdata'
>
> This issue is first reported by Joel Stanley 
> The sed one-liner is credited to Anuj Mittal 
>
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-kernel/perf/perf.bb | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 6d1b06693d..a6fb51d3db 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -239,11 +239,8 @@ do_configure_prepend () {
>  fi
>  
>  # use /usr/bin/env instead of version specific python
> -for s in `find ${S}/tools/perf/ -name '*.py'`; do
> -sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/python3,/usr/bin/env python3,' "${s}"
> +for s in `find ${S}/tools/perf/ -name '*.py'` 
> ${S}/scripts/bpf_helpers_doc.py; do
> +sed -i -e "s,#!.*python.*,#!${USRBINPATH}/env python3," ${s}
>  done
>  
>  # unistd.h can be out of sync between libc-headers and the captured 
> version in the perf source

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cryptodev-module: Fix build failure with kernel v5.5

2020-02-16 Thread He Zhe

Ping.

Zhe

On 2/10/20 9:11 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> Backport from upstream to fix the following build failure.
>
> cryptlib.c:162:37: error: 'crypto_ablkcipher_type' undeclared
> (first use in this function); did you mean 'crypto_skcipher_tfm'?
> 162 |   if ((tfm->__crt_alg->cra_type == &crypto_ablkcipher_type)
> | ^~
> | crypto_skcipher_tfm
> cryptlib.c:169:25: error: 'struct crypto_alg' has no member named
> 'cra_ablkcipher'
> 169 |alg = &tfm->__crt_alg->cra_ablkcipher;
> | ^~
> cryptlib.c:170:21: error: dereferencing pointer to incomplete type
> 'struct ablkcipher_alg'
> 170 |min_keysize = alg->min_keysize;
> | ^~
>
> Signed-off-by: He Zhe 
> ---
>  .../cryptodev/cryptodev-module_1.10.bb|  1 +
>  ...-cryptlib.c-fix-build-on-kernel-v5.5.patch | 49 +++
>  2 files changed, 50 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/cryptodev/files/0001-cryptlib.c-fix-build-on-kernel-v5.5.patch
>
> diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb 
> b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
> index 552eb6abaa..89b52d8d95 100644
> --- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
> +++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
> @@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
>  
>  SRC_URI += " \
>  file://0001-Disable-installing-header-file-provided-by-another-p.patch \
> +file://0001-cryptlib.c-fix-build-on-kernel-v5.5.patch \
>  "
>  
>  EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
> diff --git 
> a/meta/recipes-kernel/cryptodev/files/0001-cryptlib.c-fix-build-on-kernel-v5.5.patch
>  
> b/meta/recipes-kernel/cryptodev/files/0001-cryptlib.c-fix-build-on-kernel-v5.5.patch
> new file mode 100644
> index 00..1af9aed8d8
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/cryptodev/files/0001-cryptlib.c-fix-build-on-kernel-v5.5.patch
> @@ -0,0 +1,49 @@
> +From 98b163a23f6b9fbdc18c3644cf94a75cdcd0cc80 Mon Sep 17 00:00:00 2001
> +From: Andrei Botila 
> +Date: Wed, 27 Nov 2019 09:53:37 +0200
> +Subject: [PATCH] cryptlib.c: fix build on kernel v5.5+
> +
> +Starting with kernel v5.5-rc1 ablkcipher and blkcipher are removed and
> +symmetric key operations will rely solely on skcipher:
> +commit d63007eb954 ("crypto: ablkcipher - remove deprecated and unused 
> ablkcipher support").
> +
> +When cryptodev will use higher kernel versions > 5.4 will need to use the
> +skcipher interface instead.
> +
> +Signed-off-by: Andrei Botila 
> +
> +Upstream-Status: Backport 
> [https://github.com/cryptodev-linux/cryptodev-linux/
> +commit/98b163a23f6b9fbdc18c3644cf94a75cdcd0cc80]
> +
> +Signed-off-by: He Zhe 
> +
> +---
> + cryptlib.c | 5 -
> + 1 file changed, 4 insertions(+), 1 deletion(-)
> +
> +diff --git a/cryptlib.c b/cryptlib.c
> +index 4a87037..e2a4198 100644
> +--- a/cryptlib.c
>  b/cryptlib.c
> +@@ -159,6 +159,7 @@ int cryptodev_cipher_init(struct cipher_data *out, const 
> char *alg_name,
> + 
> + #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
> + tfm = crypto_skcipher_tfm(out->async.s);
> ++#if (LINUX_VERSION_CODE <= KERNEL_VERSION(5, 4, 0))
> + if ((tfm->__crt_alg->cra_type == &crypto_ablkcipher_type)
> + #if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0))
> + || (tfm->__crt_alg->cra_type == &crypto_givcipher_type)
> +@@ -169,7 +170,9 @@ int cryptodev_cipher_init(struct cipher_data *out, const 
> char *alg_name,
> + alg = &tfm->__crt_alg->cra_ablkcipher;
> + min_keysize = alg->min_keysize;
> + max_keysize = alg->max_keysize;
> +-} else {
> ++} else
> ++#endif
> ++{
> + struct skcipher_alg *alg;
> + 
> + alg = crypto_skcipher_alg(out->async.s);
> +-- 
> +2.7.4
> +

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] ltp: file01: Fix in was not recognized

2019-07-02 Thread He Zhe

Kindly ping.

Zhe

On 4/22/19 4:55 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> Some file has "pie" appending after LSB or MSB, which causes mismatch and the
> following error.
>
> "file01 10 TFAIL: in: was not recognized"
> ..."ELF 64-bit LSB pie executable"...
>
> This patches tunes the regulation expression to include those cases.
>
> Signed-off-by: He Zhe 
> ---
> v1 to v2: Move Upstream-Status to right place
>
>  .../0001-file01.sh-Fix-in-was-not-recognized.patch | 38 
> ++
>  meta/recipes-extended/ltp/ltp_20190115.bb  |  1 +
>  2 files changed, 39 insertions(+)
>  create mode 100644 
> meta/recipes-extended/ltp/ltp/0001-file01.sh-Fix-in-was-not-recognized.patch
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0001-file01.sh-Fix-in-was-not-recognized.patch
>  
> b/meta/recipes-extended/ltp/ltp/0001-file01.sh-Fix-in-was-not-recognized.patch
> new file mode 100644
> index 000..5cd9e08
> --- /dev/null
> +++ 
> b/meta/recipes-extended/ltp/ltp/0001-file01.sh-Fix-in-was-not-recognized.patch
> @@ -0,0 +1,38 @@
> +From 974e9b862e503c50501079e6586f81918e94a849 Mon Sep 17 00:00:00 2001
> +From: He Zhe 
> +Date: Fri, 19 Apr 2019 17:57:48 +0800
> +Subject: [PATCH] file01.sh: Fix in was not recognized
> +
> +Some file has "pie" appending after LSB or MSB, which causes mismatch and the
> +following error.
> +
> +"file01 10 TFAIL: in: was not recognized"
> +..."ELF 64-bit LSB pie executable"...
> +
> +This patches tunes the regulation expression to include those cases.
> +
> +Upstream-Status: Submitted 
> [http://lists.linux.it/pipermail/ltp/2019-April/011758.html]
> +
> +Signed-off-by: He Zhe 
> +---
> + testcases/commands/file/file01.sh | 4 +++-
> + 1 file changed, 3 insertions(+), 1 deletion(-)
> +
> +diff --git a/testcases/commands/file/file01.sh 
> b/testcases/commands/file/file01.sh
> +index 0a8119e..55c0433 100755
> +--- a/testcases/commands/file/file01.sh
>  b/testcases/commands/file/file01.sh
> +@@ -91,7 +91,9 @@ do_test()
> +  9) file_test in.m4 "M4 macro processor script, ASCII text" \
> + "ASCII M4 macro language pre-processor text";;
> + 10) file_test in "ELF .*-bit $TEST_ARCH executable, .*" \
> +- "ELF .*-bit $TEST_ARCH shared object, .*";;
> ++ "ELF .*-bit $TEST_ARCH shared object, .*" \
> ++ "ELF .*-bit $TEST_ARCH pie executable, .*" \
> ++ "ELF .*-bit $TEST_ARCH pie shared object, .*";;
> + 11) file_test in.ar "current ar archive";;
> + 12) file_test in.tar "tar archive";;
> + 13) file_test in.tar.gz "gzip compressed data, .*";;
> +-- 
> +2.7.4
> +
> diff --git a/meta/recipes-extended/ltp/ltp_20190115.bb 
> b/meta/recipes-extended/ltp/ltp_20190115.bb
> index 1d0c00b..a9e025a 100644
> --- a/meta/recipes-extended/ltp/ltp_20190115.bb
> +++ b/meta/recipes-extended/ltp/ltp_20190115.bb
> @@ -50,6 +50,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
> file://define-sigrtmin-and-sigrtmax-for-musl.patch \
> file://setregid01-security-string-formatting.patch \
> 
> file://0001-syscalls-setrlimit03.c-read-proc-sys-fs-nr_open-for-.patch \
> +   file://0001-file01.sh-Fix-in-was-not-recognized.patch \
> "
>  
>  S = "${WORKDIR}/git"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: cve/meltdown.c: Fix kernel symbol finding

2019-08-27 Thread He Zhe




On 8/27/19 11:56 PM, Richard Purdie wrote:
> On Tue, 2019-08-27 at 12:38 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> Backport a patch to fix the following error.
>> safe_file_ops.c:219: BROK: Expected 3 conversions got 2 at
>> meltdown.c:272
>>
>> Signed-off-by: He Zhe 
>> ---
>>  ...-cve-meltdown.c-Fix-kernel-symbol-finding.patch | 83
>> ++
>>  meta/recipes-extended/ltp/ltp_20190517.bb  |  1 +
>>  2 files changed, 84 insertions(+)
>>  create mode 100644 meta/recipes-extended/ltp/ltp/0001-cve-
>> meltdown.c-Fix-kernel-symbol-finding.patch
> Patch doesn't apply, how was this tested?

Sorry, my test environment messed up with upstream ltp.
v2 will be sent.

Zhe

>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/981/steps/8/logs/step1b
>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core] [PATCH] ltp: syscalls: rt_sigwaitinfo01: Fix failure for MIPS arches

2019-09-03 Thread He Zhe

Kindly ping.

Zhe

On 8/23/19 3:26 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> Add a patch to fix the following failure.
> rt_sigtimedwait011  TFAIL  :  .../sigwaitinfo01.c:58: test_empty_set
> (.../sigwaitinfo01.c: 148): Unexpected failure:
> TEST_ERRNO=EINVAL(22): Invalid argument
>
> Signed-off-by: He Zhe 
> ---
>  ..._sigwaitinfo01-Fix-failure-for-MIPS-arche.patch | 49 
> ++
>  meta/recipes-extended/ltp/ltp_20190517.bb  |  1 +
>  2 files changed, 50 insertions(+)
>  create mode 100644 
> meta/recipes-extended/ltp/ltp/0001-syscalls-rt_sigwaitinfo01-Fix-failure-for-MIPS-arche.patch
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0001-syscalls-rt_sigwaitinfo01-Fix-failure-for-MIPS-arche.patch
>  
> b/meta/recipes-extended/ltp/ltp/0001-syscalls-rt_sigwaitinfo01-Fix-failure-for-MIPS-arche.patch
> new file mode 100644
> index 000..9a0df74
> --- /dev/null
> +++ 
> b/meta/recipes-extended/ltp/ltp/0001-syscalls-rt_sigwaitinfo01-Fix-failure-for-MIPS-arche.patch
> @@ -0,0 +1,49 @@
> +From b4193bc3fdeb278abc54944b4773ffa45ee432af Mon Sep 17 00:00:00 2001
> +From: He Zhe 
> +Date: Fri, 23 Aug 2019 14:34:43 +0800
> +Subject: [LTP] [PATCH] syscalls: rt_sigwaitinfo01: Fix failure for MIPS 
> arches
> +
> +rt_sigtimedwait01 fails as follow on MIPS arches
> +rt_sigtimedwait011  TFAIL  :  .../sigwaitinfo01.c:58: test_empty_set
> +(.../sigwaitinfo01.c: 148): Unexpected failure:
> +TEST_ERRNO=EINVAL(22): Invalid argument
> +
> +As this case purposely bypasses glibc, it should align with the size of 
> kernel
> +definition of sigset_t which is different from other arches.
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/signal.h#n15
> +
> +This patch adds specific case for MIPS.
> +
> +Upstream-Status: Submitted 
> [http://lists.linux.it/pipermail/ltp/2019-August/013313.html]
> +Signed-off-by: He Zhe 
> +---
> + testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c | 13 ++---
> + 1 file changed, 10 insertions(+), 3 deletions(-)
> +
> +diff --git a/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c 
> b/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c
> +index 5a32ce1..5c2fa99 100644
> +--- a/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c
>  b/testcases/kernel/syscalls/sigwaitinfo/sigwaitinfo01.c
> +@@ -128,9 +128,16 @@ static int my_sigtimedwait(const sigset_t * set, 
> siginfo_t * info,
> + static int my_rt_sigtimedwait(const sigset_t * set, siginfo_t * info,
> +   struct timespec *timeout)
> + {
> +-
> +-/* The last argument is (number_of_signals)/(bits_per_byte), which are 
> 64 and 8, resp. */
> +-return ltp_syscall(__NR_rt_sigtimedwait, set, info, timeout, 8);
> ++/* The last argument is (number_of_signals)/(bits_per_byte), which are 
> 64 and 8, resp,
> ++ * except for MIPS which are 128 and 8, resp.
> ++ */
> ++return ltp_syscall(__NR_rt_sigtimedwait, set, info, timeout,
> ++#ifdef __mips__
> ++16
> ++#else
> ++8
> ++#endif
> ++);
> + }
> + #endif
> + 
> +-- 
> +2.7.4
> +
> diff --git a/meta/recipes-extended/ltp/ltp_20190517.bb 
> b/meta/recipes-extended/ltp/ltp_20190517.bb
> index b0e2f96..14c1219 100644
> --- a/meta/recipes-extended/ltp/ltp_20190517.bb
> +++ b/meta/recipes-extended/ltp/ltp_20190517.bb
> @@ -45,6 +45,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
> file://0002-check-for-RES_USE_INET6-during-configure.patch \
> 
> file://0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch \
> file://0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch \
> +   
> file://0001-syscalls-rt_sigwaitinfo01-Fix-failure-for-MIPS-arche.patch \
> "
>  
>  S = "${WORKDIR}/git"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core] [PATCH] ltp: syscalls: rt_sigwaitinfo01: Fix failure for MIPS arches

2019-09-03 Thread He Zhe




On 9/3/19 5:16 PM, Ross Burton wrote:
> On 03/09/2019 08:55, He Zhe wrote:
>> Kindly ping.
>
> This doesn't apply to current master, can you please rebase?

Oops, v2 is sent.

Thanks,
Zhe

>
> Ross
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] qemu: Add pkg-config handling for libgcrypt

2019-09-03 Thread He Zhe

Kindly ping.

Zhe

On 8/29/19 9:15 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> When PACKAGECONFIG libgcrypt is enabled, we would get the following error.
>
> ERROR: /usr/bin/libgcrypt-config should not be used, use an alternative such 
> as pkg-config
>
> In oe-core, libgcrypt has been turned to be configured with pkg-config instead
> of libgcrypt-config, but qemu configure script does not contain pkg-config
> related part for libgcrypt to handle it.
>
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-devtools/qemu/qemu.inc|  1 +
>  ...ure-Add-pkg-config-handling-for-libgcrypt.patch | 93 
> ++
>  2 files changed, 94 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/qemu/qemu/0010-configure-Add-pkg-config-handling-for-libgcrypt.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index d2dd2bc..3eeba6e 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -22,6 +22,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> file://0007-apic-fixup-fallthrough-to-PIC.patch \
> 
> file://0008-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \
> file://0009-Fix-webkitgtk-builds.patch \
> +   file://0010-configure-Add-pkg-config-handling-for-libgcrypt.patch 
> \
> "
>  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>  
> diff --git 
> a/meta/recipes-devtools/qemu/qemu/0010-configure-Add-pkg-config-handling-for-libgcrypt.patch
>  
> b/meta/recipes-devtools/qemu/qemu/0010-configure-Add-pkg-config-handling-for-libgcrypt.patch
> new file mode 100644
> index 000..a8ab7da
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/qemu/qemu/0010-configure-Add-pkg-config-handling-for-libgcrypt.patch
> @@ -0,0 +1,93 @@
> +From 5214dd4461f2090ef0965b4d2518f49927d61cbc Mon Sep 17 00:00:00 2001
> +From: He Zhe 
> +Date: Wed, 28 Aug 2019 19:56:28 +0800
> +Subject: [Qemu-devel] [PATCH] configure: Add pkg-config handling for 
> libgcrypt
> +
> +libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
> +handling for libgcrypt.
> +
> +Upstream-Status: Denied 
> [https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg06333.html]
> +
> +Signed-off-by: He Zhe 
> +---
> + configure | 48 
> + 1 file changed, 40 insertions(+), 8 deletions(-)
> +
> +diff --git a/configure b/configure
> +index e44e454..0f362a7 100755
> +--- a/configure
>  b/configure
> +@@ -2875,6 +2875,30 @@ has_libgcrypt() {
> + return 0
> + }
> + 
> ++has_libgcrypt_pkgconfig() {
> ++if ! has $pkg_config ; then
> ++return 1
> ++fi
> ++
> ++if ! $pkg_config --list-all | grep libgcrypt > /dev/null 2>&1 ; then
> ++return 1
> ++fi
> ++
> ++if test -n "$cross_prefix" ; then
> ++host=$($pkg_config --variable=host libgcrypt)
> ++if test "${host%-gnu}-" != "${cross_prefix%-gnu}" ; then
> ++print_error "host($host) does not match 
> cross_prefix($cross_prefix)"
> ++return 1
> ++fi
> ++fi
> ++
> ++if ! $pkg_config --atleast-version=1.5.0 libgcrypt ; then
> ++print_error "libgcrypt version is $($pkg_config --modversion 
> libgcrypt)"
> ++return 1
> ++fi
> ++
> ++return 0
> ++}
> + 
> + if test "$nettle" != "no"; then
> + pass="no"
> +@@ -2902,7 +2926,14 @@ fi
> + 
> + if test "$gcrypt" != "no"; then
> + pass="no"
> +-if has_libgcrypt; then
> ++if has_libgcrypt_pkgconfig; then
> ++gcrypt_cflags=$($pkg_config --cflags libgcrypt)
> ++if test "$static" = "yes" ; then
> ++gcrypt_libs=$($pkg_config --libs --static libgcrypt)
> ++else
> ++gcrypt_libs=$($pkg_config --libs libgcrypt)
> ++fi
> ++elif has_libgcrypt; then
> + gcrypt_cflags=$(libgcrypt-config --cflags)
> + gcrypt_libs=$(libgcrypt-config --libs)
> + # Debian has removed -lgpg-error from libgcrypt-config
> +@@ -2912,15 +2943,16 @@ if test "$gcrypt" != "no"; then
> + then
> + gcrypt_libs="$gcrypt_libs -lgpg-error"
> + fi
> ++fi
> + 
> +-# Link test to make sure the given libraries work (e.g for static).
> +-write_c_skeleton
> +-if compile_prog "" "$gcrypt_libs" ; then
> +-LIBS=&

[OE-core] "shutdown now" Hangs Since 1d453c9087f9 ("systemd: upgrade to 242")

2019-05-08 Thread He Zhe

Hi,


Since 1d453c9087f9 ("systemd: upgrade to 242"), "shutdown now" hangs like below 
where I enable systemd debug information print.

Any idea? Thanks.


[  OK  ] Stopped NFS status monitor for NFSv2/3 locking..
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Child 410 (sh) died (code=killed, status=1/HUP)
session-c1.scope: Child 410 belongs to session-c1.scope.
Child 299 (avahi-daemon) died (code=killed, status=15/TERM)
system.slice: Child 299 belongs to system.slice.
session-c1.scope: cgroup is empty
session-c1.scope: Succeeded.
session-c1.scope changed stop-sigterm -> dead
session-c1.scope: Job 277 session-c1.scope/stop finished, result=done
[  OK  ] Stopped Session c1 of user root.
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoa
session-c1.scope: Collecting.
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=UnitRema
systemd-journald.service: Received EPOLLHUP on stored fd 56 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 58 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 65 (stored), closing.
Got message type=signal sender=org.freedesktop.DBus destination=n/a 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwna
avahi-daemon.service: D-Bus name org.freedesktop.Avahi no longer registered by 
:1.1
systemd-journald.service: Received EPOLLHUP on stored fd 55 (stored), closing.
syslog.socket: Incoming traffic
syslog.socket: Suppressing connection request since unit stop is scheduled.



Zhe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Review request 0/1: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed

2019-05-09 Thread He Zhe

Please ignore.

Thanks,
Zhe

On 5/9/19 5:49 PM, zhe...@windriver.com wrote:
> From: zhe...@windriver.com Mon Sep 17 00:00:00 2001
>
> Summary: LIN1019-1252 run 'shutdown -P now' on vm and shutdown failed
> Tech Review: Qi Chen
> Gatekeeper: Robert
> Lockdown Approval (if needed): 
> Branch Tag: wr-10.19-20190505
>
> IP Statement (form link or license statement, usually automated):
> Crypto URL(s) (if needed): see 
> http://wiki.wrs.com/PBUeng/LinuxProductDivisionExportProcess
> Parent Template (where applicable):
>
>
> == Sanity Issues: (DO NOT EDIT this section) ==
>
>
>
> == Impacted area Impact y/n ==
> docs/tech-pubs  n
> tests   n
> build systemn
> host dependencies   n
> RPM/packaging   n
> toolchain   n
> kernel code n
> user code   y
> configuration files n
> target configurationn
> Applicable to Yocto/upstreamn
> New Kernel Warnings n
> Other   n
>
>
> == Comments (indicate scope for each "y" above) ==
> * Conditions of submission
>
> * Documentation Changes/Release Notes
>   = Doc changes
>
>   = Release notes
>
> * Git logs
>
>
> == Testing ==
> * Commands
> setup.sh --machine qemux86-64 --distro wrlinux --dl-layers
> . ./oe-init-build-env
> bitbake wrlinux-image-glibc-std
> runqemu qemux86-64 nographic
> root
> shutdown now
>
> * Expected Results
> shut down successfully
>
> * Applicable to
>
> * Tested configurations
>
>   Archbuilt  boot boardname
>   -
>   MIPS  n n
>   MIPS64n n
>   MIPS64n32 n n
>   ARM32 n n
>   ARM64 n n
>   x86   n n
>   x86_64n y   22015
>   PPC   n n
>   PPC64 n n
>   SPARC64   n n
>
>
> == Reviewer Checklist ==
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
> http://lxgit.wrs.com/cgit/bin.git/tree/etc/review.txt
>
>
> == PULLs ==
> * The branch is made of: __
>   git://128.224.158.51/git/oe-core zhe/wr-10.19-20190505__1__20190509174633
>
> * WRH-PULLs ("wrh -m" can merge it):
>   
> git://128.224.158.51/git/oe-core__s__zhe/wr-10.19-20190505__1__20190509174633

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-12 Thread He Zhe




On 6/12/19 6:49 AM, Richard Purdie wrote:
> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> For the moment,
>> 0001~0004 are on master branch only.
>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>> yet.
>>
>> Signed-off-by: He Zhe 
>> ---
>> v2: Correct a typo in SOB for 0001*.patch
> I just discussed this with lttng upstream maintainers a little. We're
> going to have continual tension between keeping lttng-modules up to
> date and new kernel versions.
>
> How about we also have a git version of this particular recipe which
> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
> PREFERRED_VERSION when using newer kernels?
>
> That should keep people using very recent kernels happy, let us use a
> stable release version and avoid us adding/removing large patchsets on
> a semi regular basis?
>
> Would you be willing to try/submit such a git recipe?

OK. I'll send a git recipe.

Regards,
Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lttng-modules: Add git based recipe

2019-06-12 Thread He Zhe




On 6/12/19 5:57 PM, Richard Purdie wrote:
> On Wed, 2019-06-12 at 17:15 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> This is based on meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb and is for
>> those who want to build lttng-modules with bleeding edge kernel, to avoid
>> regularly backporting patches from upstream.
>>
>> Note that PREFERRED_VERSION needs to be set to select this recipe instead of 
>> the
>> tar ball one.
>>
>> Signed-off-by: He Zhe 
>> ---
>>  meta/recipes-kernel/lttng/lttng-modules_git.bb | 34 
>> ++
>>  1 file changed, 34 insertions(+)
>>  create mode 100644 meta/recipes-kernel/lttng/lttng-modules_git.bb
> Do we really want/need to duplicate the whole recipe?

Do you like one .inc plus two .bb s? Then I'll send v2 later.

Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-12 Thread He Zhe




On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
> - On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@stusta.de wrote:
>
>> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>>> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>>>> From: He Zhe 
>>>>
>>>> For the moment,
>>>> 0001~0004 are on master branch only.
>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>>> yet.
>>>>
>>>> Signed-off-by: He Zhe 
>>>> ---
>>>> v2: Correct a typo in SOB for 0001*.patch
>>> I just discussed this with lttng upstream maintainers a little. We're
>>> going to have continual tension between keeping lttng-modules up to
>>> date and new kernel versions.
>>>
>>> How about we also have a git version of this particular recipe which
>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>> PREFERRED_VERSION when using newer kernels?
>> Yocto stable series will ship a _git AUTOREV recipe?
>>
>>> That should keep people using very recent kernels happy, let us use a
>>> stable release version and avoid us adding/removing large patchsets on
>>> a semi regular basis?
>>> ...
>> The semi regular basis is only slightly moved, or how and when will
>> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
>>
>> IMHO it would be better to acknowledge that this is a case where staying
>> at stable release versions is sometimes not the best option, and upgrade
>> the normal recipe to -rc releases or even a git snapshot from a more
>> recent stable branch when necessary.
>>
>> E.g. right now it seems clear that the next Yocto release will have
>> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
>> from 2.10.9 to 2.11.0-rc5 would be logical.
> Please don't base distributions on -rc tags. They are not meant for this.
>
> We always integrate support for newer kernel versions instrumentation back
> into our current stable release. So as soon as 5.2 final comes out, we will
> release a 2.10.x version including support for it in lttng-modules.

I'm one of the people who need to use lttng-modules on rc kernel.

>
> The current 2.10.10 has commits to support the currently known 5.2-rc
> instrumentation changes.

Seems v2.10.10 does not contains the 7 needed patches in my v1 for kernel v5.0+.
$ git pull
Already up-to-date.
$ git tag|grep v2.10.10
v2.10.10
$ git tag --contains 92da05ce1f73488a57e7fd79e9c03113cefdb76f
$ git tag --contains d88e2fe5c3ea0d2c3055fba824be17223c418854
$ git tag --contains d6cd2c9598a06f0ba1ba885bbe754e8836528310
$ git tag --contains 2ca0c84f0b4a915c555a0b83102d94ac941619ca
$ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
v2.11.0-rc5
$ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
v2.11.0-rc5
$ git tag --contains df0e746a05a267384785d66c9fca947eb4a9e517
v2.11.0-rc5
$ git tag --contains 9f70b60c19abc6dc0811e427ed5da4aa74620aca
v2.11.0-rc5

Thanks,
Zhe

>
> Thanks,
>
> Mathieu
>
>
>>> Cheers,
>>>
>>> Richard
>> cu
>> Adrian
>>
>> --
>>
>>   "Is there not promise of rain?" Ling Tan asked suddenly out
>>of the darkness. There had been need of rain for many days.
>>   "Only a promise," Lao Er said.
>>Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] lttng-modules: Add git based recipe

2019-06-12 Thread He Zhe




On 6/12/19 6:27 PM, richard.pur...@linuxfoundation.org wrote:
> On Wed, 2019-06-12 at 18:21 +0800, He Zhe wrote:
>> On 6/12/19 5:57 PM, Richard Purdie wrote:
>>> On Wed, 2019-06-12 at 17:15 +0800, zhe...@windriver.com wrote:
>>>> From: He Zhe 
>>>>
>>>> This is based on meta/recipes-kernel/lttng/lttng-
>>>> modules_2.10.9.bb and is for
>>>> those who want to build lttng-modules with bleeding edge kernel,
>>>> to avoid
>>>> regularly backporting patches from upstream.
>>>>
>>>> Note that PREFERRED_VERSION needs to be set to select this recipe
>>>> instead of the
>>>> tar ball one.
>>>>
>>>> Signed-off-by: He Zhe 
>>>> ---
>>>>  meta/recipes-kernel/lttng/lttng-modules_git.bb | 34
>>>> ++
>>>>  1 file changed, 34 insertions(+)
>>>>  create mode 100644 meta/recipes-kernel/lttng/lttng-
>>>> modules_git.bb
>>> Do we really want/need to duplicate the whole recipe?
>> Do you like one .inc plus two .bb s? Then I'll send v2 later.
> Yes, or just require the other .bb file and override the pieces needed.
> Not quite sure which would look best right now.
>
> Ultimately I'd like to have something like Ross' patch:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=ross/gitup
>
> and use that for cases like this. Requiring the .bb and then tweaking
> may allow migration to something like this more easily.

It's been renamed with devupstream. I'll send v3.

Thanks,
Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-12 Thread He Zhe




On 6/12/19 7:29 PM, Mathieu Desnoyers wrote:
> - On Jun 12, 2019, at 1:10 PM, zhe he zhe...@windriver.com wrote:
>
>> On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
>>> - On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@stusta.de wrote:
>>>
>>>> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>>>>> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>>>>>> From: He Zhe 
>>>>>>
>>>>>> For the moment,
>>>>>> 0001~0004 are on master branch only.
>>>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>>>>> yet.
>>>>>>
>>>>>> Signed-off-by: He Zhe 
>>>>>> ---
>>>>>> v2: Correct a typo in SOB for 0001*.patch
>>>>> I just discussed this with lttng upstream maintainers a little. We're
>>>>> going to have continual tension between keeping lttng-modules up to
>>>>> date and new kernel versions.
>>>>>
>>>>> How about we also have a git version of this particular recipe which
>>>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>>>> PREFERRED_VERSION when using newer kernels?
>>>> Yocto stable series will ship a _git AUTOREV recipe?
>>>>
>>>>> That should keep people using very recent kernels happy, let us use a
>>>>> stable release version and avoid us adding/removing large patchsets on
>>>>> a semi regular basis?
>>>>> ...
>>>> The semi regular basis is only slightly moved, or how and when will
>>>> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
>>>>
>>>> IMHO it would be better to acknowledge that this is a case where staying
>>>> at stable release versions is sometimes not the best option, and upgrade
>>>> the normal recipe to -rc releases or even a git snapshot from a more
>>>> recent stable branch when necessary.
>>>>
>>>> E.g. right now it seems clear that the next Yocto release will have
>>>> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
>>>> from 2.10.9 to 2.11.0-rc5 would be logical.
>>> Please don't base distributions on -rc tags. They are not meant for this.
>>>
>>> We always integrate support for newer kernel versions instrumentation back
>>> into our current stable release. So as soon as 5.2 final comes out, we will
>>> release a 2.10.x version including support for it in lttng-modules.
>> I'm one of the people who need to use lttng-modules on rc kernel.
>>
>>> The current 2.10.10 has commits to support the currently known 5.2-rc
>>> instrumentation changes.
>> Seems v2.10.10 does not contains the 7 needed patches in my v1 for kernel 
>> v5.0+.
>> $ git pull
>> Already up-to-date.
>> $ git tag|grep v2.10.10
>> v2.10.10
>> $ git tag --contains 92da05ce1f73488a57e7fd79e9c03113cefdb76f
>> $ git tag --contains d88e2fe5c3ea0d2c3055fba824be17223c418854
>> $ git tag --contains d6cd2c9598a06f0ba1ba885bbe754e8836528310
>> $ git tag --contains 2ca0c84f0b4a915c555a0b83102d94ac941619ca
>> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
>> v2.11.0-rc5
>> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
>> v2.11.0-rc5
>> $ git tag --contains df0e746a05a267384785d66c9fca947eb4a9e517
>> v2.11.0-rc5
>> $ git tag --contains 9f70b60c19abc6dc0811e427ed5da4aa74620aca
>> v2.11.0-rc5
> You're aware that the commit ID changes when we cherry-pick
> a commit right ?
>
> Please double-check with the commit names...

Sorry, my mistake. They've been there.

Zhe

>
> Thanks,
>
> Mathieu
>
>
>> Thanks,
>> Zhe
>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>> cu
>>>> Adrian
>>>>
>>>> --
>>>>
>>>>   "Is there not promise of rain?" Ling Tan asked suddenly out
>>>>of the darkness. There had been need of rain for many days.
>>>>   "Only a promise," Lao Er said.
>>>>Pearl S. Buck - Dragon Seed

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] lttng-modules: Add git based recipe

2019-06-13 Thread He Zhe




On 6/12/19 8:36 PM, Richard Purdie wrote:
> On Wed, 2019-06-12 at 19:12 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> The git based recipe is for those who want to build lttng-modules with 
>> bleeding
>> edge kernel, to avoid regularly backporting patches from upstream.
>>
>> Note that PREFERRED_VERSION needs to be set to select the git recipe instead 
>> of
>> the tar ball one.
>>
>> Signed-off-by: He Zhe 
>> ---
>> v2: Correct a typo in SOB in 0001
>> v3: Use devupstream to make it more clean and clear
>>
>>  meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb 
>> b/meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb
>> index 70a6843..dfd166a 100644
>> --- a/meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb
>> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb
>> @@ -11,7 +11,6 @@ inherit module
>>  
>>  COMPATIBLE_HOST = 
>> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
>>  
>> -#https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
>>  SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
>> 
>> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
>> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>> @@ -34,3 +33,13 @@ python do_package_prepend() {
>>  bb.warn("%s: no modules were created; this may be due to 
>> CONFIG_TRACEPOINTS not being enabled in your kernel." % d.getVar('PN'))
>>  }
>>  
>> +BBCLASSEXTEND = "devupstream:target"
>> +LIC_FILES_CHKSUM_class-devupstream = 
>> "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
>> +DEFAULT_PREFERENCE_class-devupstream = "-1"
>> +SRC_URI_class-devupstream = 
>> "git://git.lttng.org/lttng-modules;branch=master \
>> +   
>> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
>> +   file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>> +   "
>> +SRCREV_class-devupstream = "${AUTOREV}"
>> +PV_class-devupstream = "2.11.0-rc+git${SRCPV}"
>> +S_class-devupstream = "${WORKDIR}/git"
> OE-Core can't access the network by default so this will need to be a
> specific SRCREV which you can set to AUTOREV in local config if that
> makes sense.
>
> I've sent a separate email to openembedded-architecture about a better
> syntax for some of this but that isn't anything wrong with this patch,
> more just the way devupstream works.

Thanks. I assumed this patch was on the way to be merged. But with Jonathan
Rajotte-Julien's idea coming after your comment, I want to make sure if there's
anything/update I should do for the patch.

Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-13 Thread He Zhe




On 6/12/19 10:52 PM, Jonathan Rajotte-Julien wrote:
> Hi,
>
>>> Please don't base distributions on -rc tags. They are not meant for this.
>>>
>>> We always integrate support for newer kernel versions instrumentation back
>>> into our current stable release. So as soon as 5.2 final comes out, we will
>>> release a 2.10.x version including support for it in lttng-modules.
>> I'm one of the people who need to use lttng-modules on rc kernel.
> If so, please use a git based recipe building the HEAD of the latest released
> stable branch (stable-2.10 currently since 2.11 is in currently in the RC
> stage). If you have problem, report them on our mailing list [1] or our bug
> tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla
> kernel [3] and other usual suspects [4]. We normally catch those problems
> quite quickly. Keep in mind that in no way should a production image be built
> with a non tagged release.
>
> As for the oe-core recipe, please send us a quick email to let us know, patch
> level releases are cheap. Keep in mind that we are chasing a moving target
> here.
>
> To add to Mathieu statement, not only do we integrate support for newer 
> kernels into
> the current stable branch but also in all the supported stable branch when
> possible. The supported stable release are normally the 3 latest minor-level 
> releases.
> Currently this set is : 2.8, 2.9, 2.10 .
>
> [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> [2] https://bugs.lttng.org/
> [3] An example of such job running: 
> https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console
> This job validate that lttng-modules master builds against the following 
> vanilla kernel tags. We have
> similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable 
> 2.10 lttng-modules branch.
>   v3.0.101
>   v3.1.10
>   v3.2.102
>   v3.3.8
>   v3.4.113
>   v3.5.7
>   v3.6.11
>   v3.7.10
>   v3.8.13
>   v3.9.11
>   v3.10.108
>   v3.11.10
>   v3.12.74
>   v3.13.11
>   v3.14.79
>   v3.15.10
>   v3.16.68
>   v3.17.8
>   v3.18.140
>   v3.19.8
>   v4.0.9
>   v4.1.52
>   v4.2.8
>   v4.3.6
>   v4.4.181
>   v4.5.7
>   v4.6.7
>   v4.7.10
>   v4.8.17
>   v4.9.181
>   v4.10.17
>   v4.11.12
>   v4.12.14
>   v4.13.16
>   v4.14.125
>   v4.15.18
>   v4.16.18
>   v4.17.19
>   v4.18.20
>   v4.19.50
>   v4.20.17
>   v5.0.21
>   v5.1.9
>   v5.2-rc4
> [4] https://ci.lttng.org/view/LTTng-modules/

Thanks for your great input.

Zhe

>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-25 Thread He Zhe




On 6/12/19 6:57 AM, Bruce Ashfield wrote:
> On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
>  wrote:
>> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>>> From: He Zhe 
>>>
>>> For the moment,
>>> 0001~0004 are on master branch only.
>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>> yet.
>>>
>>> Signed-off-by: He Zhe 
>>> ---
>>> v2: Correct a typo in SOB for 0001*.patch
>> I just discussed this with lttng upstream maintainers a little. We're
>> going to have continual tension between keeping lttng-modules up to
>> date and new kernel versions.
>>
>> How about we also have a git version of this particular recipe which
>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>> PREFERRED_VERSION when using newer kernels?
>>
>> That should keep people using very recent kernels happy, let us use a
>> stable release version and avoid us adding/removing large patchsets on
>> a semi regular basis?
>>
>> Would you be willing to try/submit such a git recipe?
> This makes sense to me as well, since I'm one of the folks that runs
> into this issue the most. In fact, I've been carrying a local _git
> version of the lttng recipe for over a year, since I didn't feel like
> getting into the _git versus release tarballs debate. This solution
> should avoid that debate and keep all the different versions of
> kernels moving along.

Hi Bruce and Richard,

BTW, how about using git for all cases so that people don't have to maintain a
tarball locally? Though I don't have the background knowledge of that git vs
tarball debate mentioned above.

Zhe

>
> Bruce
>
>> Cheers,
>>
>> Richard
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

2019-06-25 Thread He Zhe




On 6/25/19 4:04 PM, richard.pur...@linuxfoundation.org wrote:
> On Tue, 2019-06-25 at 15:59 +0800, He Zhe wrote:
>> On 6/12/19 6:57 AM, Bruce Ashfield wrote:
>>> On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
>>>  wrote:
>>>> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>>>>> From: He Zhe 
>>>>>
>>>>> For the moment,
>>>>> 0001~0004 are on master branch only.
>>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been
>>>>> released
>>>>> yet.
>>>>>
>>>>> Signed-off-by: He Zhe 
>>>>> ---
>>>>> v2: Correct a typo in SOB for 0001*.patch
>>>> I just discussed this with lttng upstream maintainers a little.
>>>> We're
>>>> going to have continual tension between keeping lttng-modules up
>>>> to
>>>> date and new kernel versions.
>>>>
>>>> How about we also have a git version of this particular recipe
>>>> which
>>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>>> PREFERRED_VERSION when using newer kernels?
>>>>
>>>> That should keep people using very recent kernels happy, let us
>>>> use a
>>>> stable release version and avoid us adding/removing large
>>>> patchsets on
>>>> a semi regular basis?
>>>>
>>>> Would you be willing to try/submit such a git recipe?
>>> This makes sense to me as well, since I'm one of the folks that
>>> runs
>>> into this issue the most. In fact, I've been carrying a local _git
>>> version of the lttng recipe for over a year, since I didn't feel
>>> like
>>> getting into the _git versus release tarballs debate. This solution
>>> should avoid that debate and keep all the different versions of
>>> kernels moving along.
>> Hi Bruce and Richard,
>>
>> BTW, how about using git for all cases so that people don't have to
>> maintain a
>> tarball locally? Though I don't have the background knowledge of that
>> git vs
>> tarball debate mentioned above.
> The overhead of tarball releases is much lower than git trees for each
> piece of software so I'd prefer to have tarball recipes where we can,
> it does lead to faster builds.

Got it, thanks.

Zhe

>
> Cheers,
>
> Richard
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ltp: Fix copy_file_rang02 for 32-bit arches

2020-06-23 Thread He Zhe

From: He Zhe 

Fix the following error.
copy_file_range02.c:139: FAIL: copy_file_range failed unexpectedly; expected 
EOVERFLOW, but got: EFBIG (27)

Signed-off-by: He Zhe 
---
 ...le_range02-Expect-EFBIG-in-subcase-m.patch | 57 +++
 meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
 2 files changed, 58 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch
 
b/meta/recipes-extended/ltp/ltp/0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch
new file mode 100644
index 00..0c082f04a5
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch
@@ -0,0 +1,57 @@
+From 99687ab002f9f750f6f18fa1d70a91f0aa4f8ba2 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Thu, 18 Jun 2020 17:18:27 +0800
+Subject: [PATCH] syscalls/copy_file_range02: Expect EFBIG in subcase max
+ length on 32-bit architectures
+
+For syscall
+ssize_t copy_file_range(int fd_in, loff_t *off_in,
+   int fd_out, loff_t *off_out,
+   size_t len, unsigned int flags);
+off_out is loff_t* that is long long, 64 bits on 32-bit architectures,
+while len is size_t that unsigned int, 32 bits on 32-bit architectures.
+
+In subcase "max length", simplified as below,
+
+dst = tst_max_lfs_filesize();
+TEST(sys_copy_file_range(fd_src, 0, *tc->copy_to_fd, &dst, tc->len, 
tc->flags));
+
+where dst is 4K*4G and len is 4G, so (4K+1)*4G is always smaller than 4G*4G,
+it can never match the following kernel condition on 32-bit architectures.
+
+if (pos_in + count < pos_in || pos_out + count < pos_out)
+   return -EOVERFLOW;
+
+And thus we would get error like
+copy_file_range02.c:139: FAIL: copy_file_range failed unexpectedly; expected 
EOVERFLOW, but got: EFBIG (27)
+
+Also correct a typo.
+
+Upstream-Status: Accepted 
[http://lists.linux.it/pipermail/ltp/2020-June/017716.html]
+
+Signed-off-by: He Zhe 
+Acked-by: Li Wang 
+---
+ .../kernel/syscalls/copy_file_range/copy_file_range02.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c 
b/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c
+index fa679c4d3..bc27fbe57 100644
+--- a/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c
 b/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c
+@@ -78,7 +78,11 @@ static struct tcase {
+   {&fd_chrdev,0,  EINVAL, CONTSIZE,   "char device",  
0},
+   {&fd_fifo,  0,  EINVAL, CONTSIZE,   "fifo", 
0},
+   {&fd_pipe[0],   0,  EINVAL, CONTSIZE,   "pipe", 
0},
+-  {&fd_copy,  0,  EOVERFLOW,  ULLONG_MAX, "max length 
lenght",1},
++#ifdef TST_ABI64
++  {&fd_copy,  0,  EOVERFLOW,  ULLONG_MAX, "max length",   
1},
++#else
++  {&fd_copy,  0,  EFBIG,  ULLONG_MAX, "max length",   
1},
++#endif
+   {&fd_copy,  0,  EFBIG,  MIN_OFF,"max file 
size",1},
+ };
+ 
+-- 
+2.17.1
+
diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index f2510baa68..b283add12f 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -36,6 +36,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0001-Add-more-musl-exclusions.patch \
file://0001-ptrace01-Fix-missing-format-string.patch \

file://0001-sigwaitinfo-Do-not-run-invalid-undefined-test-cases.patch \
+   
file://0001-syscalls-copy_file_range02-Expect-EFBIG-in-subcase-m.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139817): 
https://lists.openembedded.org/g/openembedded-core/message/139817
Mute This Topic: https://lists.openembedded.org/mt/75056214/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] cryptodev-module: Backport a patch to fix build failure with kernel v5.8

2020-07-20 Thread He Zhe

From: He Zhe 

Fix the following build failure with linux-yocto-dev

zc.c:61:17: error: 'struct mm_struct' has no member named 'mmap_sem';
did you mean 'mmap_base'?
   61 |  down_read(&mm->mmap_sem);
  | ^~~~
  | mmap_base
zc.c:77:15: error: 'struct mm_struct' has no member named 'mmap_sem';
did you mean 'mmap_base'?
   77 |  up_read(&mm->mmap_sem);
  |       ^~~~
  |   mmap_base

Signed-off-by: He Zhe 
---
 .../cryptodev/cryptodev-module_1.10.bb|  1 +
 .../0001-Fix-build-for-Linux-5.8-rc1.patch| 49 +++
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch

diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb 
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
index 552eb6abaa..6474599c45 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
+++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.10.bb
@@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
 
 SRC_URI += " \
 file://0001-Disable-installing-header-file-provided-by-another-p.patch \
+file://0001-Fix-build-for-Linux-5.8-rc1.patch \
 "
 
 EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
diff --git 
a/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch 
b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
new file mode 100644
index 00..02c721a4f3
--- /dev/null
+++ b/meta/recipes-kernel/cryptodev/files/0001-Fix-build-for-Linux-5.8-rc1.patch
@@ -0,0 +1,49 @@
+From 9e765068582aae3696520346a7500322ca6cc2de Mon Sep 17 00:00:00 2001
+From: Joan Bruguera 
+Date: Sat, 13 Jun 2020 19:46:44 +0200
+Subject: [PATCH] Fix build for Linux 5.8-rc1
+
+See also: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9740ca4e95b43b91a4a848694a20d01ba6818f7b
+  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da1c55f1b272f4bd54671d459b39ea7b54944ef9
+  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d8ed45c5dcd455fc5848d47f86883a1b872ac0d0
+
+Signed-off-by: Joan Bruguera 
+
+Upstream-Status: Backport [9e765068582aae3696520346a7500322ca6cc2de]
+
+Signed-off-by: He Zhe 
+---
+ zc.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/zc.c b/zc.c
+index ae464ff..2c286bb 100644
+--- a/zc.c
 b/zc.c
+@@ -58,7 +58,11 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   return 0;
+   }
+ 
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0))
+   down_read(&mm->mmap_sem);
++#else
++  mmap_read_lock(mm);
++#endif
+ #if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 6, 0))
+   ret = get_user_pages(task, mm,
+   (unsigned long)addr, pgcount, write, 0, pg, NULL);
+@@ -74,7 +78,11 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int 
write,
+   (unsigned long)addr, pgcount, write ? FOLL_WRITE : 0,
+   pg, NULL, NULL);
+ #endif
++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0))
+   up_read(&mm->mmap_sem);
++#else
++  mmap_read_unlock(mm);
++#endif
+   if (ret != pgcount)
+   return -EINVAL;
+ 
+-- 
+2.17.1
+
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140799): 
https://lists.openembedded.org/g/openembedded-core/message/140799
Mute This Topic: https://lists.openembedded.org/mt/75677752/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe-core][PATCH] lttng-modules: Backport a patch to fix btrfs build failure

2020-11-23 Thread He Zhe

lttng-modules-2.12.3/probes/lttng-probe-btrfs.c:36:
lttng-modules-2.12.3/probes/../probes/lttng-tracepoint-event-impl.h:131:6:
error: conflicting types for 'trace_find_free_extent'

Signed-off-by: He Zhe 
---
 ...oints-output-proper-root-owner-for-t.patch | 318 ++
 .../lttng/lttng-modules_2.12.3.bb |   1 +
 2 files changed, 319 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-btrfs-tracepoints-output-proper-root-owner-for-t.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-btrfs-tracepoints-output-proper-root-owner-for-t.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-btrfs-tracepoints-output-proper-root-owner-for-t.patch
new file mode 100644
index 00..956f53d7b7
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-btrfs-tracepoints-output-proper-root-owner-for-t.patch
@@ -0,0 +1,318 @@
+From e13a7d262928984154fcf89feb14098e0cd1ad31 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 27 Oct 2020 11:42:23 -0400
+Subject: [PATCH 04/11] fix: btrfs: tracepoints: output proper root owner for
+ trace_find_free_extent() (v5.10)
+
+See upstream commit :
+
+  commit 437490fed3b0c9ae21af8f70e0f338d34560842b
+  Author: Qu Wenruo 
+  Date:   Tue Jul 28 09:42:49 2020 +0800
+
+btrfs: tracepoints: output proper root owner for trace_find_free_extent()
+
+The current trace event always output result like this:
+
+ find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 
flags=4(METADATA)
+ find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 
flags=4(METADATA)
+ find_free_extent: root=2(EXTENT_TREE) len=8192 empty_size=0 flags=1(DATA)
+ find_free_extent: root=2(EXTENT_TREE) len=8192 empty_size=0 flags=1(DATA)
+ find_free_extent: root=2(EXTENT_TREE) len=4096 empty_size=0 flags=1(DATA)
+ find_free_extent: root=2(EXTENT_TREE) len=4096 empty_size=0 flags=1(DATA)
+
+T's saying we're allocating data extent for EXTENT tree, which is not
+even possible.
+
+It's because we always use EXTENT tree as the owner for
+trace_find_free_extent() without using the @root from
+btrfs_reserve_extent().
+
+This patch will change the parameter to use proper @root for
+trace_find_free_extent():
+
+Now it looks much better:
+
+ find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 
flags=36(METADATA|DUP)
+ find_free_extent: root=5(FS_TREE) len=8192 empty_size=0 flags=1(DATA)
+ find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 flags=1(DATA)
+ find_free_extent: root=5(FS_TREE) len=4096 empty_size=0 flags=1(DATA)
+ find_free_extent: root=5(FS_TREE) len=8192 empty_size=0 flags=1(DATA)
+ find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 
flags=36(METADATA|DUP)
+ find_free_extent: root=7(CSUM_TREE) len=16384 empty_size=0 
flags=36(METADATA|DUP)
+ find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 
flags=36(METADATA|DUP)
+ find_free_extent: root=1(ROOT_TREE) len=16384 empty_size=0 
flags=36(METADATA|DUP)
+
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Mathieu Desnoyers 
+Change-Id: I1d674064d29b31417e2acffdeb735f5052a87032
+
+Upstream-Status: Backport
+
+Signed-off-by: He Zhe 
+---
+ instrumentation/events/lttng-module/btrfs.h | 206 
+ 1 file changed, 122 insertions(+), 84 deletions(-)
+
+diff --git a/instrumentation/events/lttng-module/btrfs.h 
b/instrumentation/events/lttng-module/btrfs.h
+index 7b29008..52fcfd0 100644
+--- a/instrumentation/events/lttng-module/btrfs.h
 b/instrumentation/events/lttng-module/btrfs.h
+@@ -1856,7 +1856,29 @@ LTTNG_TRACEPOINT_EVENT_INSTANCE(btrfs__reserved_extent, 
 btrfs_reserved_extent_f
+ 
+ #endif /* #else #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4,10,0)) */
+ 
+-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,10,0) || \
++  LTTNG_KERNEL_RANGE(5,9,6, 5,10,0) || \
++  LTTNG_KERNEL_RANGE(5,4,78, 5,5,0))
++LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent,
++
++  btrfs_find_free_extent,
++
++  TP_PROTO(const struct btrfs_root *root, u64 num_bytes, u64 empty_size,
++   u64 data),
++
++  TP_ARGS(root, num_bytes, empty_size, data),
++
++  TP_FIELDS(
++  ctf_array(u8, fsid, root->lttng_fs_info_fsid, BTRFS_UUID_SIZE)
++  ctf_integer(u64, root_objectid, root->root_key.objectid)
++  ctf_integer(u64, num_bytes, num_bytes)
++  ctf_integer(u64, empty_size, empty_size)
++  ctf_integer(u64, data, data)
++  )
++)
++
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(5,5,0))
++
+ LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent,
+ 
+   btrfs_find_free_extent,
+@@ -1874,6 +1896,105 @@ LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent,
+   )
+ )
+ 
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(4,18,0))
++
++LTTNG_TRACEPOINT_EVENT_MAP(find_free_extent,
++
++  btr

[OE-core][PATCH] runqemu: Change nfs to mount via TCP

2020-03-27 Thread He Zhe

From: He Zhe 

Since kernel commit b24ee6c64ca7 ("NFS: allow deprecation of NFS UDP protocol"),
NFS UDP has been disabled by default due to the potential data corruption caused
by fragmentation during high loads. So now we cannot boot up with nfs mode and
default kernel.

We'd better turn to use TCP accordingly.

Signed-off-by: He Zhe 
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 6f24093d77..6a77e3db9a 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -990,7 +990,7 @@ class BaseConfig(object):
 # Use '%s' since they are integers
 os.putenv(k, '%s' % v)
 
-self.unfs_opts="nfsvers=3,port=%s,udp,mountport=%s" % (nfsd_port, 
mountd_port)
+self.unfs_opts="nfsvers=3,port=%s,tcp,mountport=%s" % (nfsd_port, 
mountd_port)
 
 # Extract .tar.bz2 or .tar.bz if no nfs dir
 if not (self.rootfs and os.path.isdir(self.rootfs)):
-- 
2.24.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#136793): 
https://lists.openembedded.org/g/openembedded-core/message/136793
Mute This Topic: https://lists.openembedded.org/mt/72582553/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] glibc: Disable CPU ISA level requirement check

2021-02-26 Thread He Zhe

We experience the following error and fail to boot on qemu64 machine

/lib64/libc.so.6: CPU ISA level is lower than required
Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00

As stated in [1],

Passing -march= causes glibc to add annotations not compatible to run
result on -march= as too high ISA level is inferred.

ISA level is a new feature of 2.33 release.

Until it's fixed let's disable ISA level inference with
libc_cv_include_x86_isa_level=no
(no better configure option yet).

[1] 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5dbd6a821ff753e3b41324c4fb7c58cf65eeea33

Signed-off-by: He Zhe 
---
 meta/recipes-core/glibc/glibc.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index d2f02ad59b..7d14306377 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -20,6 +20,7 @@ CACHED_CONFIGUREVARS += " \
   libc_cv_ssp_strong=no \
   libc_cv_ssp_all=no \
   libc_cv_ssp=no \
+  libc_cv_include_x86_isa_level=no \
 "
 
 # ifunc doesn't appear to work on mips, casuses libbfd assertion failures
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148654): 
https://lists.openembedded.org/g/openembedded-core/message/148654
Mute This Topic: https://lists.openembedded.org/mt/80927819/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] linux-yocto-dev: add features/scsi/scsi-debug.scc features/gpio/mockup.scc to KERNEL_FEATURES

2021-04-09 Thread He Zhe

Add features/scsi/scsi-debug.scc and features/gpio/mockup.scc to
KERNEL_FEATURES to meet ptest requirement as what we did for other
linux-yocto*.

Signed-off-by: He Zhe 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 8725473d1c..ee41d612fd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -50,5 +50,7 @@ KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "", d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "", d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc", "", d)}"
 
 KERNEL_VERSION_SANITY_SKIP = "1"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150331): 
https://lists.openembedded.org/g/openembedded-core/message/150331
Mute This Topic: https://lists.openembedded.org/mt/81963464/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] kernel: Fix QA buildpaths warning for kernel modules

2018-02-07 Thread He Zhe

Hi Bruce,

I should have cc this to you.

Thanks,
Zhe

On 2018年02月05日 14:54, zhe...@windriver.com wrote:
> From: He Zhe 
>
> CFLAGS is unset during kernel_do_compile and thus the default build
> path substitutions in DEBUG_PREFIX_MAP are missing.
>
> To enhance reproducible build for kernel modules, such as lttng-modules
> and cryptodev-module, this patch appends them, plus substitution of
> STAGING_KERNEL_DIR, to KERNEL_CC.
>
> Signed-off-by: He Zhe 
> ---
>  meta/classes/kernel-arch.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/kernel-arch.bbclass 
> b/meta/classes/kernel-arch.bbclass
> index cf0edb6..e0fe22b 100644
> --- a/meta/classes/kernel-arch.bbclass
> +++ b/meta/classes/kernel-arch.bbclass
> @@ -57,7 +57,7 @@ HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
>  TARGET_AR_KERNEL_ARCH ?= ""
>  HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
>  
> -KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd"
> +KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd 
> ${DEBUG_PREFIX_MAP} 
> -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
>  KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
>  KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
>  TOOLCHAIN = "gcc"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core][PATCH] curl: Fix build failure for qemuriscv64

2022-07-12 Thread He Zhe

Backport a patch from upstream to fix the following build failure.

tmp-glibc/work/riscv64-wrs-linux/curl/7.84.0-r0/recipe-sysroot-native/
usr/bin/riscv64-wrs-linux/../../libexec/riscv64-wrs-linux/gcc/
riscv64-wrs-linux/12.1.0/ld: ../lib/.libs/libcurl.so:
undefined reference to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status

Signed-off-by: He Zhe 
---
 meta/recipes-support/curl/curl_7.84.0.bb  |  1 +
 ...-to-using-atomic_int-instead-of-bool.patch | 37 +++
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-support/curl/files/0001-easy_lock-switch-to-using-atomic_int-instead-of-bool.patch

diff --git a/meta/recipes-support/curl/curl_7.84.0.bb 
b/meta/recipes-support/curl/curl_7.84.0.bb
index 0d829cdf23..28b09ef017 100644
--- a/meta/recipes-support/curl/curl_7.84.0.bb
+++ b/meta/recipes-support/curl/curl_7.84.0.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=190c514872597083303371684954f238"
 SRC_URI = " \
 https://curl.se/download/${BP}.tar.xz \
 file://0001-easy_lock.h-include-sched.h-if-available-to-fix-buil.patch \
+file://0001-easy_lock-switch-to-using-atomic_int-instead-of-bool.patch \
 file://run-ptest \
 file://disable-tests \
 "
diff --git 
a/meta/recipes-support/curl/files/0001-easy_lock-switch-to-using-atomic_int-instead-of-bool.patch
 
b/meta/recipes-support/curl/files/0001-easy_lock-switch-to-using-atomic_int-instead-of-bool.patch
new file mode 100644
index 00..878839a5e3
--- /dev/null
+++ 
b/meta/recipes-support/curl/files/0001-easy_lock-switch-to-using-atomic_int-instead-of-bool.patch
@@ -0,0 +1,37 @@
+From 50efb0822aa0e0ab165158dd0a26e65a2290e6d2 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Tue, 28 Jun 2022 09:00:25 +0200
+Subject: [PATCH] easy_lock: switch to using atomic_int instead of bool
+
+To work with more compilers without requiring separate libs to
+link. Like with gcc-12 for RISC-V on Linux.
+
+Reported-by: Adam Sampson
+Fixes #9055
+Closes #9061
+
+Upstream-Status: Backport [50efb0822aa0e0ab165158dd0a26e65a2290e6d2]
+
+Signed-off-by: He Zhe 
+---
+ lib/easy_lock.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/easy_lock.h b/lib/easy_lock.h
+index 07c85c5ff..9c11bc50c 100644
+--- a/lib/easy_lock.h
 b/lib/easy_lock.h
+@@ -40,8 +40,8 @@
+ #include 
+ #endif
+ 
+-#define curl_simple_lock atomic_bool
+-#define CURL_SIMPLE_LOCK_INIT false
++#define curl_simple_lock atomic_int
++#define CURL_SIMPLE_LOCK_INIT 0
+ 
+ static inline void curl_simple_lock_lock(curl_simple_lock *lock)
+ {
+-- 
+2.25.1
+
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167904): 
https://lists.openembedded.org/g/openembedded-core/message/167904
Mute This Topic: https://lists.openembedded.org/mt/92328587/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH] lttng-modules: Fix build failure for kernel v5.15.58

2022-08-01 Thread He Zhe

Backport from upstream d8254360c7f2ff9b3f945e9668d89c0b56b9bd91
("fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)")

tmp-glibc/work/qemuarm-wrs-linux-gnueabi/lttng-modules/2.13.3-r0/
lttng-modules-2.13.3/src/probes/../../include/lttng/
tracepoint-event-impl.h:133:6:
error: conflicting types for 'trace_kfree_skb'; have 'void(struct sk_buff *, 
void *)'
  133 | void trace_##_name(_proto);
  |      ^~

Signed-off-by: He Zhe 
---
 ...oduce-kfree_skb_reason-v5.15.58.v5.1.patch | 51 +++
 .../lttng/lttng-modules_2.13.4.bb |  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
new file mode 100644
index 00..0140c4b989
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
@@ -0,0 +1,51 @@
+From d8254360c7f2ff9b3f945e9668d89c0b56b9bd91 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers 
+Date: Fri, 29 Jul 2022 15:37:43 -0400
+Subject: [PATCH] fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)
+
+See upstream commit :
+
+  commit c504e5c2f9648a1e5c2be01e8c3f59d394192bd3
+  Author: Menglong Dong 
+  Date:   Sun Jan 9 14:36:26 2022 +0800
+
+net: skb: introduce kfree_skb_reason()
+
+Introduce the interface kfree_skb_reason(), which is able to pass
+the reason why the skb is dropped to 'kfree_skb' tracepoint.
+
+Add the 'reason' field to 'trace_kfree_skb', therefor user can get
+more detail information about abnormal skb with 'drop_monitor' or
+eBPF.
+
+All drop reasons are defined in the enum 'skb_drop_reason', and
+they will be print as string in 'kfree_skb' tracepoint in format
+of 'reason: XXX'.
+
+( Maybe the reasons should be defined in a uapi header file, so that
+user space can use them? )
+
+Signed-off-by: Mathieu Desnoyers 
+Change-Id: Ib3c039207739dad10f097cf76474e0822e351273
+---
+ include/instrumentation/events/skb.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/include/instrumentation/events/skb.h 
b/include/instrumentation/events/skb.h
+index 237e54ad..186732ea 100644
+--- a/include/instrumentation/events/skb.h
 b/include/instrumentation/events/skb.h
+@@ -13,7 +13,9 @@
+ /*
+  * Tracepoint for free an sk_buff:
+  */
+-#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(5,17,0))
++#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(5,17,0) \
++  || LTTNG_KERNEL_RANGE(5,15,58, 5,16,0))
++
+ LTTNG_TRACEPOINT_ENUM(skb_drop_reason,
+   TP_ENUM_VALUES(
+   ctf_enum_value("NOT_SPECIFIED", SKB_DROP_REASON_NOT_SPECIFIED)
+-- 
+2.17.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
index ea2ec3c380..fea0e383c9 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \

file://0001-fix-mm-page_alloc-fix-tracepoint-mm_page_alloc_zone_.patch \

file://0002-fix-fs-Remove-flags-parameter-from-aops-write_begin-.patch \

file://0003-fix-workqueue-Fix-type-of-cpu-in-trace-event-v5.19.patch \
+   
file://0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch \
"
 
 # Use :append here so that the patch is applied also when using devupstream
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168743): 
https://lists.openembedded.org/g/openembedded-core/message/168743
Mute This Topic: https://lists.openembedded.org/mt/92743102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH] lttng-modules: Fix build failure for kernel v5.15.58

2022-08-01 Thread He Zhe



On 8/1/22 21:04, Luca Ceresoli wrote:
> Hello He,
>
> On Mon,  1 Aug 2022 16:51:36 +0800
> "He Zhe"  wrote:
>
>> Backport from upstream d8254360c7f2ff9b3f945e9668d89c0b56b9bd91
>> ("fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)")
>>
>> tmp-glibc/work/qemuarm-wrs-linux-gnueabi/lttng-modules/2.13.3-r0/
>> lttng-modules-2.13.3/src/probes/../../include/lttng/
>> tracepoint-event-impl.h:133:6:
>> error: conflicting types for 'trace_kfree_skb'; have 'void(struct sk_buff *, 
>> void *)'
>>   133 | void trace_##_name(_proto);
>>   |  ^~
>>
>> Signed-off-by: He Zhe 
>> ---
>>  ...oduce-kfree_skb_reason-v5.15.58.v5.1.patch | 51 +++
>>  .../lttng/lttng-modules_2.13.4.bb |  1 +
>>  2 files changed, 52 insertions(+)
>>  create mode 100644 
>> meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
>>
>> diff --git 
>> a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
>>  
>> b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
>> new file mode 100644
>> index 00..0140c4b989
>> --- /dev/null
>> +++ 
>> b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
>> @@ -0,0 +1,51 @@
>> +From d8254360c7f2ff9b3f945e9668d89c0b56b9bd91 Mon Sep 17 00:00:00 2001
>> +From: Mathieu Desnoyers 
>> +Date: Fri, 29 Jul 2022 15:37:43 -0400
>> +Subject: [PATCH] fix: net: skb: introduce kfree_skb_reason() 
>> (v5.15.58..v5.16)
>> +
>> +See upstream commit :
>> +
>> +  commit c504e5c2f9648a1e5c2be01e8c3f59d394192bd3
>> +  Author: Menglong Dong 
>> +  Date:   Sun Jan 9 14:36:26 2022 +0800
>> +
>> +net: skb: introduce kfree_skb_reason()
>> +
>> +Introduce the interface kfree_skb_reason(), which is able to pass
>> +the reason why the skb is dropped to 'kfree_skb' tracepoint.
>> +
>> +Add the 'reason' field to 'trace_kfree_skb', therefor user can get
>> +more detail information about abnormal skb with 'drop_monitor' or
>> +eBPF.
>> +
>> +All drop reasons are defined in the enum 'skb_drop_reason', and
>> +they will be print as string in 'kfree_skb' tracepoint in format
>> +of 'reason: XXX'.
>> +
>> +( Maybe the reasons should be defined in a uapi header file, so that
>> +user space can use them? )
>> +
>> +Signed-off-by: Mathieu Desnoyers 
>> +Change-Id: Ib3c039207739dad10f097cf76474e0822e351273
> Missing Upstream-status tag here.

Thanks. resent.

Zhe

>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168763): 
https://lists.openembedded.org/g/openembedded-core/message/168763
Mute This Topic: https://lists.openembedded.org/mt/92743102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH] lttng-modules: Fix build failure for kernel v5.15.58

2022-08-01 Thread He Zhe

Backport from upstream d8254360c7f2ff9b3f945e9668d89c0b56b9bd91
("fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)")

tmp-glibc/work/qemuarm-wrs-linux-gnueabi/lttng-modules/2.13.3-r0/
lttng-modules-2.13.3/src/probes/../../include/lttng/
tracepoint-event-impl.h:133:6:
error: conflicting types for 'trace_kfree_skb'; have 'void(struct sk_buff *, 
void *)'
  133 | void trace_##_name(_proto);
  |      ^~

Signed-off-by: He Zhe 
---
 ...oduce-kfree_skb_reason-v5.15.58.v5.1.patch | 53 +++
 .../lttng/lttng-modules_2.13.4.bb |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
new file mode 100644
index 00..ca6abea9c0
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch
@@ -0,0 +1,53 @@
+From d8254360c7f2ff9b3f945e9668d89c0b56b9bd91 Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers 
+Date: Fri, 29 Jul 2022 15:37:43 -0400
+Subject: [PATCH] fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)
+
+See upstream commit :
+
+  commit c504e5c2f9648a1e5c2be01e8c3f59d394192bd3
+  Author: Menglong Dong 
+  Date:   Sun Jan 9 14:36:26 2022 +0800
+
+net: skb: introduce kfree_skb_reason()
+
+Introduce the interface kfree_skb_reason(), which is able to pass
+the reason why the skb is dropped to 'kfree_skb' tracepoint.
+
+Add the 'reason' field to 'trace_kfree_skb', therefor user can get
+more detail information about abnormal skb with 'drop_monitor' or
+eBPF.
+
+All drop reasons are defined in the enum 'skb_drop_reason', and
+they will be print as string in 'kfree_skb' tracepoint in format
+of 'reason: XXX'.
+
+( Maybe the reasons should be defined in a uapi header file, so that
+user space can use them? )
+
+Upstream-Status: Backport
+
+Signed-off-by: Mathieu Desnoyers 
+Change-Id: Ib3c039207739dad10f097cf76474e0822e351273
+---
+ include/instrumentation/events/skb.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/include/instrumentation/events/skb.h 
b/include/instrumentation/events/skb.h
+index 237e54ad..186732ea 100644
+--- a/include/instrumentation/events/skb.h
 b/include/instrumentation/events/skb.h
+@@ -13,7 +13,9 @@
+ /*
+  * Tracepoint for free an sk_buff:
+  */
+-#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(5,17,0))
++#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(5,17,0) \
++  || LTTNG_KERNEL_RANGE(5,15,58, 5,16,0))
++
+ LTTNG_TRACEPOINT_ENUM(skb_drop_reason,
+   TP_ENUM_VALUES(
+   ctf_enum_value("NOT_SPECIFIED", SKB_DROP_REASON_NOT_SPECIFIED)
+-- 
+2.17.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
index ea2ec3c380..fea0e383c9 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.13.4.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \

file://0001-fix-mm-page_alloc-fix-tracepoint-mm_page_alloc_zone_.patch \

file://0002-fix-fs-Remove-flags-parameter-from-aops-write_begin-.patch \

file://0003-fix-workqueue-Fix-type-of-cpu-in-trace-event-v5.19.patch \
+   
file://0001-fix-net-skb-introduce-kfree_skb_reason-v5.15.58.v5.1.patch \
"
 
 # Use :append here so that the patch is applied also when using devupstream
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168764): 
https://lists.openembedded.org/g/openembedded-core/message/168764
Mute This Topic: https://lists.openembedded.org/mt/92743102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] linux-yocto-dev: Set KBRANCH with =

2022-01-10 Thread He Zhe

The "?=" assignment to KBRANCH in kernel-yocto.bbclass is selected prior to
the one in this recipe and makes it "master" as a result.

Change the KBRANCH assignment back to "=" as how it was done before.

Signed-off-by: He Zhe 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 80f62a0412..0d94637352 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -16,7 +16,7 @@ inherit pkgconfig
 # provide this .inc to set specific revisions
 include recipes-kernel/linux/linux-yocto-dev-revisions.inc
 
-KBRANCH ?= "v5.16/standard/base"
+KBRANCH = "v5.16/standard/base"
 KMETA = "kernel-meta"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine \
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160385): 
https://lists.openembedded.org/g/openembedded-core/message/160385
Mute This Topic: https://lists.openembedded.org/mt/88341669/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH] lttng-tools: Disable ptest for qemuriscv32

2022-09-22 Thread He Zhe

lttng-tools ptest requires SYS_ppoll and SYS_pselect which are not
supported by qemuriscv32.

Back port a not merged patch from upstream to be able to disable the test
build and disable the ptest build for qemuriscv32. This way the main
package can still be used or at least built.

See the following link for more details.
https://github.com/lttng/lttng-tools/pull/162

Signed-off-by: He Zhe 
---
 meta/recipes-kernel/lttng/lttng-platforms.inc |  4 ++
 .../0001-configure.ac-add-disable-tests.patch | 38 +++
 .../lttng/lttng-tools_2.13.8.bb   |  6 ++-
 3 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-configure.ac-add-disable-tests.patch

diff --git a/meta/recipes-kernel/lttng/lttng-platforms.inc 
b/meta/recipes-kernel/lttng/lttng-platforms.inc
index 933c65d85d..2351df08b8 100644
--- a/meta/recipes-kernel/lttng/lttng-platforms.inc
+++ b/meta/recipes-kernel/lttng/lttng-platforms.inc
@@ -15,3 +15,7 @@ LTTNGUST:arc = ""
 
 COMPATIBLE_HOST:arc:pn-lttng-ust = "null"
 
+# Whether the platform supports lttng-tools-ptest
+# lttng-tools-ptest uses syscall SYS_ppoll and SYS_pselect6 which are not 
supported for some platforms.
+LTTNGTOOLSPTEST = "ptest"
+LTTNGTOOLSPTEST:qemuriscv32 = ""
diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-configure.ac-add-disable-tests.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-configure.ac-add-disable-tests.patch
new file mode 100644
index 00..05e976ec49
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-configure.ac-add-disable-tests.patch
@@ -0,0 +1,38 @@
+From 787978985d6ddd86561f16ad88a12e1570d3e46b Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Wed, 21 Sep 2022 23:07:03 -0700
+Subject: [PATCH] configure.ac: add --disable-tests
+
+Allow the user to explicitly disable tests
+
+Signed-off-by: Fabrice Fontaine 
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: He Zhe 
+---
+ configure.ac | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 5bfe791..a90e590 100644
+--- a/configure.ac
 b/configure.ac
+@@ -884,6 +884,8 @@ AC_ARG_ENABLE([bin-lttng-sessiond], 
AS_HELP_STRING([--disable-bin-lttng-sessiond
+ [Disable the build of lttng-sessiond binaries]))
+ AC_ARG_ENABLE([extras], AS_HELP_STRING([--disable-extras],
+ [Disable the build of the extra components]))
++AC_ARG_ENABLE([tests], AS_HELP_STRING([--disable-tests],
++[Disable the build of the test components]))
+ 
+ 
+ build_lib_consumer=no
+@@ -1035,6 +1037,7 @@ AM_CONDITIONAL([BUILD_BIN_LTTNG_SESSIOND], [test 
x$enable_bin_lttng_sessiond !=
+ 
+ # Export the tests and extras build conditions.
+ AS_IF([\
++test "x$enable_tests" != "xno" && \
+ test "x$enable_bin_lttng" != "xno" && \
+ test "x$enable_bin_lttng_consumerd" != "xno" && \
+ test "x$enable_bin_lttng_crash" != "xno" && \
+-- 
+2.37.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.13.8.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.13.8.bb
index a814eb79f9..883c930cdb 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.13.8.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.13.8.bb
@@ -25,11 +25,12 @@ PYTHON_OPTION = 
"am_cv_python_pyexecdir='${PYTHON_SITEPACKAGES_DIR}' \
  am_cv_python_pythondir='${PYTHON_SITEPACKAGES_DIR}' \
  
PYTHON_INCLUDE='-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}' \
 "
-PACKAGECONFIG ??= "${LTTNGUST} kmod"
+PACKAGECONFIG ??= "${LTTNGUST} ${LTTNGTOOLSPTEST} kmod"
 PACKAGECONFIG[python] = "--enable-python-bindings ${PYTHON_OPTION},,python3 
swig-native"
 PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust"
 PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
 PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages, 
asciidoc-native xmlto-native libxslt-native"
+PACKAGECONFIG[ptest] = ",--disable-tests"
 
 SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-tests-do-not-strip-a-helper-library.patch \
@@ -37,11 +38,12 @@ SRC_URI = 
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://lttng-sessiond.service \
file://determinism.patch \
file://disable-tests.patch \
+   file://0001-configure.ac-add-disable-tests.patch \
"
 
 SRC_URI[sha256sum] = 
"b1e959579b260790930b20f3c7aa7cefb8a40e0de80d4a777c2bf78c6b353dc1"
 
-inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
+inherit autotools ${@bb.utils.filter('LTTNGTOOLSPTEST', 'ptest', d)} pkgconfig 
useradd python3-dir manpages systemd
 
 CAC

1 2 >

1 - 100 of 115 matches

Mail list logo