[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+NYUBMhYq4vVzrR@1wt.eu>
Date: Wed, 8 Feb 2023 09:07:44 +0100
From: Willy Tarreau <w@....eu>
To: Feiyang Chen <chris.chenfeiyang@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>,
"Paul E. McKenney" <paulmck@...nel.org>,
Feiyang Chen <chenfeiyang@...ngson.cn>,
Huacai Chen <chenhuacai@...nel.org>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] nolibc: Add statx() support to implement sys_stat()
On Wed, Feb 08, 2023 at 03:42:56PM +0800, Feiyang Chen wrote:
> Hi, Arnd, Willy,
>
> We have a problem if we just start with sys_statx() only on this arch.
> When struct stat is not defined, what should we do with stat() in the
> nolibc selftest?
You need to have a struct stat regardless of the syscalls you implement,
because it is what userland will see and use. Even if your implementation
of stat() is based on statx(), you'll need that struct stat that your
stat() function will feed. Right now it is defined in types.h.
As you can see in sys.h where sys_stat() is implemented, each arch's
specific syscall is used with a local sys_stat_struct that is specific
to that syscall, then the fields are stuffed into the userland-compatible
stat struct.
aarch64 is a good example, as its stat() implementation relies on
newfstatat() that uses a different one, but all fields are properly
mapped.
Just let me know if anything is not clear and if you need more help.
Thanks!
Willy
Powered by blists - more mailing lists