[OE-core] [PATCH] ltp: getrlimit03: adjust-a-bit-of-code-to-compatiable-with mips32

[Hongzhi, Song]

On 7/19/19 2:41 PM, Petr Vorel wrote:
> Hi Hongzhi,
>
>>> ...
>>>> --- /dev/null
>>>> +++ b/meta/recipes-extended/ltp/ltp/0001-getrlimit03-adjust-a-bit-of-code-to-compatiable-with.patch
>>>> @@ -0,0 +1,62 @@
>>>> +From e79652a3839869b1983d65999e5d5dcb50bc9cd7 Mon Sep 17 00:00:00 2001
>>>> +From: "Hongzhi.Song" <hongzhi.song at windriver.com>
>>>> +Date: Mon, 15 Jul 2019 03:39:06 -0400
>>>> +Subject: [PATCH] getrlimit03: adjust a bit of code to compatiable with mips32
>>> ...
>>>> +Signed-off-by: Jan Stancek <jstancek at redhat.com>
>>>> +Signed-off-by: Hongzhi.Song <hongzhi.song at windriver.com>
>>>> +
>>>> +Upstream-Status: Backport
>>>> +Signed-off-by: Hongzhi.Song <hongzhi.song at windriver.com>
>>>> +---
>>>> + testcases/kernel/syscalls/getrlimit/getrlimit03.c | 8 +++++++-
>>>> + 1 file changed, 7 insertions(+), 1 deletion(-)
>>> I have to say I prefer policy when only build fixes are backported / added.
>>> (approach which e.g. buildroot has). Having many patches (25 atm) makes updating
>>> a bit difficult (ok, not that much, 'Upstream-Status: Backport' shows what has
>>> been merged since last release) and sometimes brings users patches which weren't
>>> accepted by upstream (your mips patch [1] was not accepted [2]
>> Thanks for your kindly remind.
>> Agree with you. It's time to uprev ltp recipe.
>
>>  From now, if the "Submitting or Backport" is appropriate,
>> I will make sure the patch was merged by ltp before it was sent to oe-core.
> Great! Feel free to Cc me when sending patches.
>
>>> ).
>>> But I understand that LTP 3 months release cycle can be to
>>> slow for some LTP users.
>>> Kind regards,
>>> Petr
>>> PS: I'm slowly working on fixing all musl issues in LTP upstream. It's a long
>>> term run but were moving towards that goal.
>>> Patch "build: Add option to select libc implementation" [3] is a not a good
>>> approach.  Instead it's needed to find for each failure why it's not presented
>>> in musl.  Mostly because it uses non POSIX features or deprecated API, which
>>> needs to be avoided or used kernel headers where it's available.
>>> [1] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/ltp/ltp/0001-open_posix_testsuite-mmap24-2-Relax-condition-a-bit.patch
>> I am working on this patch.
> Good.
>
>
>>> [2] https://patchwork.ozlabs.org/patch/982194/#2012168
>> This patch has been merge by ltp finally.
> To LTP upstream? I don't see it [4]. That's the patch you working on.

Hi Petr,

quote your statement above : "[2] 
https://patchwork.ozlabs.org/patch/982194/#2012168"

https://github.com/linux-test-project/ltp/commit/7a3bca63cd7f059d490b6274f0fdf3247be93fde

--Hongzhi


>
>> --Hongzhi
>>> [3] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/ltp/ltp/0004-build-Add-option-to-select-libc-implementation.patch
> [4] https://github.com/linux-test-project/ltp/commits/master/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c
>