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.s...@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 <jstan...@redhat.com> > +Signed-off-by: Hongzhi.Song <hongzhi.s...@windriver.com> > + > +Upstream-Status: Backport > +Signed-off-by: Hongzhi.Song <hongzhi.s...@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]). 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 [2] https://patchwork.ozlabs.org/patch/982194/#2012168 [3] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/ltp/ltp/0004-build-Add-option-to-select-libc-implementation.patch -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
