Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Zhangjin Wu <falcon@tinylab.org>
To:     w@1wt.eu
Cc:     arnd@arndb.de, falcon@tinylab.org, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
        thomas@t-8ch.de
Subject: Re: [PATCH 1/4] tools/nolibc: unistd.h: add __syscall() and __syscall_ret() helpers
Date:   Mon,  5 Jun 2023 17:33:26 +0800
Message-Id: <20230605093326.156266-1-falcon@tinylab.org>
In-Reply-To: <ZH1+hkhiA2+ItSvX@1wt.eu>
References: <ZH1+hkhiA2+ItSvX@1wt.eu>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrsz:qybglogicsvrsz3a-3
Precedence: bulk

> On Mon, Jun 05, 2023 at 01:58:57PM +0800, Zhangjin Wu wrote:
> > > What about something like this:
> > > 
> > > static inline long __ret_as_errno(long ret) /* or some other name */
> > > {
> > > 	if (ret < 0) {
> > > 		SET_ERRNO(-ret);
> > > 		ret = -1;
> > > 	}
> > > 	return ret;
> > > }
> > > 
> > > This avoids another macro by using a normal function.
> > >
> > 
> > It is reasonable, like it very much.
> > 
> > > Syscall return values should always fit into long, at least
> > > extra polating from syscall(2) and the fact that they are returned in
> > > registers.
> > 
> > Yes, I did use 'long' instead of 'int' for unistd.h locally, but since tried to
> > let it work with 'void *' before (e.g. sys_brk, an older version support pass
> > the errno value), so, the typeof() is used and the same to unistd.h, but at
> > last, none of (void *) return type is really used in current patchset, so, we
> > are able to use this normal function version without the checking of the type.
> > 
> > > 
> > > It would be a bit more verbose:
> > > 
> > > int chdir(const char *path)
> > > {
> > > 	return __ret_as_errno(sys_chdir(path));
> > > }
> > >
> > > But it's clear what's going on and also just one line.
> > 
> > Thanks Thomas, It looks good and I do like the 'embedded' calling of
> > sys_chrdir(path), but __syscall() looks cleaner and shorter too, let's put them
> > together:
> > 
> > int chdir(const char *path)
> > {
> > 	return __ret_as_errno(sys_chdir(path));
> > }
> > 
> > int chdir(const char *path)
> > {
> > 	return __syscall(chdir, path);
> > }
> > 
> > And even with:
> > 
> > int chdir(const char *path)
> > {
> > 	return __sysret(sys_chdir(path));
> > }
> > 
> > __syscall() works likes syscall(), and the definition is similar to syscall(),
> > but uses the syscall name instead of syscall number, If reserve __syscall(),
> > the inline function would be renamed back to __syscall_ret() or something like
> > the shorter __sysret(), to align with our new __syscall(). 
> > 
> > for sys.h:
> > 
> >     /* Syscall return helper, set errno as ret when ret < 0 */
> >     static inline long __sysret(long ret)
> >     {
> >     	if (ret < 0) {
> >     		SET_ERRNO(-ret);
> >     		ret = -1;
> >     	}
> >     	return ret;
> >     }
> > 
> >     /* Syscall call helper, use syscall name instead of syscall number */
> >     #define __syscall(name, ...) __sysret(sys_##name(__VA_ARGS__))
> > 
> > for unistd.h:
> > 
> >     #define _syscall(N, ...) __sysret(my_syscall##N(__VA_ARGS__))
> > 
> > What about this version?
> > 
> > The potential 'issue' may be mixing the use of __syscall(), _syscall() and
> > syscall(), but the compilers may help to fix up this for us, I don't think it
> > is a bottleneck.
> 
> I think that could work. However, please place __attribute__((always_inline))
> on these inline functions, as we don't want to turn them to function calls
> even at -O0.

Thanks, done.

> 
> I'm traveling today, I'll let you and Thomas debate and decide how you'd
> like this to evolve.
> 

Happy traveling.

This revision is basically derived from the 'long' type information and
__ret_as_errno() from Thomas, I will wait suggestion from Thomas and then send
v2 later.

> Also, please note that Paul is OK with merging for 6.5, but we should
> absolutely limit last-minute changes to the strict minimum we're able
> to test now.

Strongly agree, we can delay this and the left time64 syscalls to 6.6, because
they require more cleanup and discussion.

Best regards,
Zhangjin

> 
> Thanks!
> Willy