mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Re: add loongarch64 port
Date: Thu, 31 Mar 2022 10:14:08 +0200	[thread overview]
Message-ID: <CAK8P3a1d=jHPn0CdNYROWffoyxBhj3cmXJpO_Sb10T39zFS+wg@mail.gmail.com> (raw)
In-Reply-To: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn>

On Thu, Mar 31, 2022 at 8:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> > On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:

> I do not understand what is old stat() family (pre-statx) ?  what is new ?
>
> I compare the system call  that related the stat  in musl and mainline
> kernel 5.17,
>
> they are consistent.
>
> #define __NR3264_statfs     43            /*sys_statfs*/
> #define __NR3264_fstatfs    44           /*sys_fstatfs*/
> #define __NR3264_fstatat   79          /*sys_newfstatat*/
> #define __NR3264_fstat      80            /*sys_newfstat*/
> #define __NR_statx             291           /*sys_statx*/
> #define __NR_statfs                 __NR3264_statfs
> #define __NR_fstatfs               __NR3264_fstatfs
> #define __NR_newfstatat      __NR3264_fstatat
> #define __NR_fstat                 __NR3264_fstat

The __NR_fstat and __NR_newfstatat  symbols are only defined by
the kernel if  __ARCH_WANT_NEW_STAT is set, which should not be
by the time the kernel port is merged. Instead, user space should
call statx() here, which continues to be supported as a superset.

The statfs/fstatfs  system calls are unrelated and can be used, the proposed
fsinfo() system call that was meant as a replacement has never made
it in

> > For the signal list, the stdint.h header, and the 'struct stat' and
> > 'struct kstat'
> > definitions, I would expect that there is already an architecture-independent
> > definition in musl that you can use, as these should be the same for
> > all new architectures.
>
> I understand the meaning is  define signal.h, stdint.h, struct stat and
> struct kstat in generic,
>
> LoongArch use the generic definition.
>
> can we deal with this issue separately ?
>
> 1.LoongArch port based on the existing software framework in musl.
>
> 2.implement the generic definitions in musl, LoongArch use the
>
> architecture-independent definition.

Yes, that works for me, I only care about the ABI issues: we have to
ensure that the kernel interfaces in the upstream musl port are
the same ones that are used in the upstream kernel port, to avoid
breaking applications built on these after everything is upstream.
(We can break compatibility with existing non-upstream user space
for the moment, which is the point of this review).

Any implementation details within musl that do not impact the ABI
can come later. I mainly pointed out these three because I expected
them to already have generic code in musl, given that the kernel does
not require architecture specific definitions for these. If you have custom
definitions, that introduces a certain risk that these correspond to an
earlier private kernel version of yours rather than what will become
the official port.

      Arnd

  reply	other threads:[~2022-03-31  8:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  6:20 王洪亮
2022-03-31  8:14 ` Arnd Bergmann [this message]
2022-04-01  7:40   ` 王洪亮
2022-04-01  7:48     ` Arnd Bergmann
2022-04-02  6:19       ` 王洪亮
2022-04-02  7:21         ` Rich Felker
2022-04-02  9:53           ` 王洪亮
2022-04-27  1:58   ` 王洪亮
2022-04-27  2:13     ` Rich Felker
2022-03-31 18:47 ` Rich Felker
2022-04-02  7:59   ` 王洪亮
2022-04-06  2:08     ` 王洪亮
2022-04-06 16:00       ` Markus Wichmann
2022-04-08  2:21         ` 王洪亮
2022-04-08  6:46           ` Arnd Bergmann
2022-04-09  3:54             ` 王洪亮
2022-04-09 11:06               ` Arnd Bergmann
2022-04-09 13:19                 ` Rich Felker
2022-04-09 13:30                   ` Rich Felker
2022-04-10 10:30                     ` Arnd Bergmann
2022-04-10 15:26                       ` Rich Felker
2022-04-11  8:03                         ` Arnd Bergmann
2022-04-11 12:11                           ` Rich Felker
2022-04-11 13:01                             ` Arnd Bergmann
2022-04-12  1:11                               ` 王洪亮
2022-04-13  1:16                                 ` 王洪亮
2022-04-13  7:26                       ` Christian Brauner
2022-04-13  8:26                         ` Arnd Bergmann
2022-04-13  9:04                           ` Christian Brauner
2022-04-13 13:25                             ` Arnd Bergmann
2022-04-13 14:09                               ` Rich Felker
2022-04-14  9:36                                 ` Christian Brauner
2022-04-20  9:09                                   ` 王洪亮
2022-04-20 13:33                                     ` Christian Brauner
2022-04-20 13:54                                       ` Rich Felker
2022-04-21  6:54                                         ` 王洪亮
2022-04-14  9:36                               ` Christian Brauner
2022-04-13  7:19                   ` Christian Brauner
2022-04-13 14:06                     ` Rich Felker
2022-04-11  3:40                 ` 王洪亮
  -- strict thread matches above, loose matches on Subject: below --
2022-03-22  3:52 [musl] " 王洪亮
2022-03-29  8:12 ` [musl] " 王洪亮
2022-03-29  8:26   ` Arnd Bergmann

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='CAK8P3a1d=jHPn0CdNYROWffoyxBhj3cmXJpO_Sb10T39zFS+wg@mail.gmail.com' \
    --to=arnd@kernel.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).