From: Zhangjin Wu <falcon@tinylab.org>
To: linux@weissschuh.net
Cc: linux-kernel@vger.kernel.org, rodrigo@sdfg.com.ar, w@1wt.eu
Subject: Re: [PATCH 1/1] tools/nolibc: Add workarounds for centos-7
Date: Sat, 7 Oct 2023 22:07:27 +0800 [thread overview]
Message-ID: <20231007140727.7399-1-falcon@tinylab.org> (raw)
In-Reply-To: <5d4d14f5-b90d-4fd7-865e-0d64b8520c0e@t-8ch.de>
Hi, Thomas
> On 2023-09-27 15:06:03+0200, Rodrigo Campos wrote:
> ...
> > For now we are work-arounding it by doing basically the same thing I'm doing
> > here:
> > https://github.com/opencontainers/runc/blob/96a61d3bf0dcc26343bfafe5112934d73d280dd3/libcontainer/dmz/xstat.h
> >
> > We then include this file before nolibc.h, and then the type works as fine:
> > https://github.com/opencontainers/runc/blob/96a61d3bf0dcc26343bfafe5112934d73d280dd3/libcontainer/dmz/_dmz.c
> >
> > Would it be acceptable for nolibc if I just define what we use:
> > * struct statx
> > * struct statx_timestamp (used inside struct statx)
> > * STATX_BASIC_STATS (or STATX_* constants too, as you prefer)
>
> Without __NR_statx this would still only result in dead code.
>
> *IF* we want to fix/work around this in nolibc it would be more like
>
> #ifdef __NR_statx
>
> /* whatever was done before */
>
> #else
>
> int stat(const char *path, struct stat *buf)
> {
> return __sysret(-ENOSYS);
> }
>
> #endif
>
> Or we drop the #else completely to make it obvious for applications that
> stat() will just not work.
This may worth a patch, sorry for my fault ;-(
And to avoid breaking the older kernel users or especially for some
older kernel books readers, and since this also has introduced some
inconvenience to Willy, perhaps it is valuable to restore original
'sys_stat' support, I will look into how or simply revert the commit but
need to add a new one for powerpc, I will learn how to avoid defining
the extra structure for the not required architectures, the
__ARCH_WANT_SYS_STAT macro may help. I'm also working on cleaning up the
old_select(), old_mmap() and sys_fork()/sys_clone() selection support,
they may be put in a series.
Willy, what about your suggestion?
Thanks,
Zhangjin Wu
prev parent reply other threads:[~2023-10-07 14:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 13:36 [PATCH 0/1] tools/nolibc: Support centos-7 Rodrigo Campos
2023-09-26 13:36 ` [PATCH 1/1] tools/nolibc: Add workarounds for centos-7 Rodrigo Campos
2023-09-26 23:30 ` Thomas Weißschuh
2023-09-27 13:06 ` Rodrigo Campos
2023-09-27 18:23 ` Thomas Weißschuh
2023-09-27 19:41 ` Rodrigo Campos
2023-10-07 14:07 ` Zhangjin Wu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231007140727.7399-1-falcon@tinylab.org \
--to=falcon@tinylab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=rodrigo@sdfg.com.ar \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®