Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-12 Thread akuster808



On 11/12/19 1:46 PM, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org > boun...@lists.openembedded.org> On Behalf Of Richard Purdie
>> Sent: den 7 november 2019 21:53
>> To: Seebs 
>> Cc: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30
>> issues
>>
>> On Thu, 2019-11-07 at 14:34 -0600, Seebs wrote:
>>> On Thu,  7 Nov 2019 20:04:44 +
>>> Richard Purdie  wrote:
>>>
>>>> Modern distros (e.g. fedora30) are starting to use the new statx()
>>>> syscall through the newly exposed glibc wrapper function in
>>>> software
>>>> like coreutils (e.g. the ls command). Add support to intercept this
>>>> to pseudo.
>>> I think this should be okay. If there's no real statx() wrapper, the
>>> real_statx() call probably fails, but also things probably won't have
>>> thought it existed/worked.
>> That was my thinking...
>>
>>> Worth double-checking that things still run with this in place on a
>>> system that doesn't have a statx wrapper, when configuring and
>>> building things like coreutils that will check for it.
>> coreutils looks to be using a standard configure check for the statx
>> function.
>>
>> Even in OE, we'd not want to configure/compile with pseudo loaded and
>> active so I think we should be ok...
>>
>> Cheers,
>>
>> Richard
> As a Fedora 30 user, I expect this needs to be backported to Zeus, 
> Warrior, etc as well or I guess I will start seeing problems when 
> building them?

this is already staged in both test branches.

- armin
>
> //Peter
>

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


Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-12 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  boun...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 7 november 2019 21:53
> To: Seebs 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30
> issues
> 
> On Thu, 2019-11-07 at 14:34 -0600, Seebs wrote:
> > On Thu,  7 Nov 2019 20:04:44 +
> > Richard Purdie  wrote:
> >
> > > Modern distros (e.g. fedora30) are starting to use the new statx()
> > > syscall through the newly exposed glibc wrapper function in
> > > software
> > > like coreutils (e.g. the ls command). Add support to intercept this
> > > to pseudo.
> >
> > I think this should be okay. If there's no real statx() wrapper, the
> > real_statx() call probably fails, but also things probably won't have
> > thought it existed/worked.
> 
> That was my thinking...
> 
> > Worth double-checking that things still run with this in place on a
> > system that doesn't have a statx wrapper, when configuring and
> > building things like coreutils that will check for it.
> 
> coreutils looks to be using a standard configure check for the statx
> function.
> 
> Even in OE, we'd not want to configure/compile with pseudo loaded and
> active so I think we should be ok...
> 
> Cheers,
> 
> Richard

As a Fedora 30 user, I expect this needs to be backported to Zeus, 
Warrior, etc as well or I guess I will start seeing problems when 
building them?

//Peter

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


Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-07 Thread Richard Purdie
On Thu, 2019-11-07 at 14:34 -0600, Seebs wrote:
> On Thu,  7 Nov 2019 20:04:44 +
> Richard Purdie  wrote:
> 
> > Modern distros (e.g. fedora30) are starting to use the new statx()
> > syscall through the newly exposed glibc wrapper function in
> > software
> > like coreutils (e.g. the ls command). Add support to intercept this
> > to pseudo.
> 
> I think this should be okay. If there's no real statx() wrapper, the
> real_statx() call probably fails, but also things probably won't have
> thought it existed/worked.

That was my thinking...

> Worth double-checking that things still run with this in place on a
> system that doesn't have a statx wrapper, when configuring and
> building things like coreutils that will check for it.

coreutils looks to be using a standard configure check for the statx
function.

Even in OE, we'd not want to configure/compile with pseudo loaded and
active so I think we should be ok...

Cheers,

Richard



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


Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-07 Thread Seebs
On Thu,  7 Nov 2019 20:04:44 +
Richard Purdie  wrote:

> Modern distros (e.g. fedora30) are starting to use the new statx()
> syscall through the newly exposed glibc wrapper function in software
> like coreutils (e.g. the ls command). Add support to intercept this
> to pseudo.

I think this should be okay. If there's no real statx() wrapper, the
real_statx() call probably fails, but also things probably won't have
thought it existed/worked.

Worth double-checking that things still run with this in place on a
system that doesn't have a statx wrapper, when configuring and building
things like coreutils that will check for it.

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


[OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-07 Thread Richard Purdie
Modern distros (e.g. fedora30) are starting to use the new statx() syscall 
through
the newly exposed glibc wrapper function in software like coreutils (e.g. the ls
command). Add support to intercept this to pseudo.

Signed-off-by: Richard Purdie 
---
 .../pseudo/files/0001-Add-statx.patch | 107 ++
 meta/recipes-devtools/pseudo/pseudo_git.bb|   1 +
 2 files changed, 108 insertions(+)
 create mode 100644 meta/recipes-devtools/pseudo/files/0001-Add-statx.patch

diff --git a/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch 
b/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
new file mode 100644
index 000..49abc2e0277
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/0001-Add-statx.patch
@@ -0,0 +1,107 @@
+From 4e41a05de1f34ba00a68ca4f20fb49c4d1cbd2d0 Mon Sep 17 00:00:00 2001
+From: Richard Purdie 
+Date: Wed, 6 Nov 2019 12:17:46 +
+Subject: [PATCH] Add statx glibc/syscall support
+
+Modern distros (e.g. fedora30) are starting to use the new statx() syscall 
through
+the newly exposed glibc wrapper function in software like coreutils (e.g. the 
ls
+command). Add support to intercept this to pseudo.
+
+Signed-off-by: Richard Purdie 
+Upstream-Status: Submitted [Emailed to seebs]
+---
+ ports/linux/guts/statx.c | 48 
+ ports/linux/portdefs.h   |  1 +
+ ports/linux/wrapfuncs.in |  1 +
+ 3 files changed, 50 insertions(+)
+ create mode 100644 ports/linux/guts/statx.c
+
+diff --git a/ports/linux/statx/guts/statx.c b/ports/linux/statx/guts/statx.c
+new file mode 100644
+index 000..a3259c4
+--- /dev/null
 b/ports/linux/statx/guts/statx.c
+@@ -0,0 +1,43 @@
++/*
++ * Copyright (c) 2019 Linux Foundation
++ * Author: Richard Purdie
++ *
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ * int
++ * statx(int dirfd, const char *pathname, int flags, unsigned int mask, 
struct statx *statxbuf) {
++ * wrap___fxstat64(int ver, int fd, struct stat64 *buf) {
++ *int rc = -1;
++ */
++  pseudo_msg_t *msg;
++  PSEUDO_STATBUF buf;
++  int save_errno;
++
++  rc = real_statx(dirfd, pathname, flags, mask, statxbuf);
++  save_errno = errno;
++  if (rc == -1) {
++  return rc;
++  }
++
++  buf.st_uid = statxbuf->stx_uid;
++  buf.st_gid = statxbuf->stx_gid;
++  buf.st_dev = makedev(statxbuf->stx_dev_major, statxbuf->stx_dev_minor);
++  buf.st_ino = statxbuf->stx_ino;
++  buf.st_mode = statxbuf->stx_mode;
++  buf.st_rdev = makedev(statxbuf->stx_rdev_major, 
statxbuf->stx_rdev_minor);
++  buf.st_nlink = statxbuf->stx_nlink;
++  msg = pseudo_client_op(OP_STAT, 0, -1, dirfd, pathname, );
++  if (msg && msg->result == RESULT_SUCCEED) {
++  pseudo_debug(PDBGF_FILE, "statx(path %s), flags %o, stat rc %d, 
stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
++  statxbuf->stx_uid = msg->uid;
++  statxbuf->stx_gid = msg->gid;
++  statxbuf->stx_mode = msg->mode;
++  statxbuf->stx_rdev_major = major(msg->rdev);
++  statxbuf->stx_rdev_minor = minor(msg->rdev);
++  } else {
++  pseudo_debug(PDBGF_FILE, "statx(path %s) failed, flags %o, stat 
rc %d, stat uid %o\n", pathname, flags, rc, statxbuf->stx_uid);
++  }
++  errno = save_errno;
++/*return rc;
++ * }
++ */
+diff --git a/ports/linux/statx/portdefs.h b/ports/linux/statx/portdefs.h
+new file mode 100644
+index 000..bf934dc
+--- /dev/null
 b/ports/linux/statx/portdefs.h
+@@ -0,0 +1,6 @@
++/*
++ * SPDX-License-Identifier: LGPL-2.1-only
++ *
++ */
++#include 
++#include 
+diff --git a/ports/linux/statx/wrapfuncs.in b/ports/linux/statx/wrapfuncs.in
+new file mode 100644
+index 000..c9cd4c3
+--- /dev/null
 b/ports/linux/statx/wrapfuncs.in
+@@ -0,0 +1 @@
++int statx(int dirfd, const char *pathname, int flags, unsigned int mask, 
struct statx *statxbuf);
+diff --git a/ports/linux/subports b/ports/linux/subports
+index a29044a..49081bf 100755
+--- a/ports/linux/subports
 b/ports/linux/subports
+@@ -54,3 +54,13 @@ else
+ fi
+ rm -f dummy.c dummy.o
+ 
++cat > dummy.c <
++struct statx x;
++EOF
++if ${CC} -c -o dummy.o dummy.c >/dev/null 2>&1; then
++  echo "linux/statx"
++fi
++rm -f dummy.c dummy.o
++
+-- 
+2.17.1
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 78500e1cc6d..1f2df4a427e 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -7,6 +7,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo \
file://moreretries.patch \
file://toomanyfiles.patch \
file://0001-maketables-wrappers-use-Python-3.patch \
+   file://0001-Add-statx.patch \
"
 
 SRCREV = "060058bb29f70b244e685b3c704eb0641b736f73"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org