mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: musl@lists.openwall.com, Christian Brauner <brauner@kernel.org>
Subject: Re: [musl] Re: add loongarch64 port
Date: Fri, 8 Apr 2022 08:46:27 +0200	[thread overview]
Message-ID: <CAK8P3a17Mrqr36Typ1F_pCUEFjG5PLQ+xrDmDdSB2M0GGK8qfw@mail.gmail.com> (raw)
In-Reply-To: <8dfcd620-4143-7450-8429-a89ed2264620@loongson.cn>

On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/4/7 上午12:00, Markus Wichmann 写道:
> > On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote:
> >> Hi, Rich
> >>
> >>
> >> within __clone() implement __NR_clone3 syscall,
> >>
> >> will that confusion between clone and clone3?
> >>
> >>
> >> Hongliang Wang
> >>
> >>
> >>
> > __clone() is a function with a defined interface. How it is implemented
> > is not given in the name. Why should __clone() have to be implemented
> > using the SYS_clone system call? If I understood the thread so far
> > correctly, the final kernel will not even have SYS_clone.
> >
> > Compare with open(), which is often implemented in terms of SYS_openat
> > instead of SYS_open. Or qsort(), which, despite the name, is rarely
> > implemented as a quicksort.
> >
> > So no, there will be no confusion of system calls because a function is
> > not implemented in terms of the system call of the same name, as long as
> > the function fulfills the defined interface.
> >
> > Ciao,
> > Markus
>
> Hi,
>
> I agree this point.
> In the implementation,I found a problem:
> In order to implement __NR_clone3 syscall in __clone(),
> I need to fill struct clone_args,I found clone_args.stack
> point to the lowest address of stack,but the input parameter
> "stack" of __clone() point to stack bottom(STACK_GROWS_DOWN),
> because of no stack_size,I can't convert between them.
> Do you have any good suggestions?

There is a good explanation from Christian Brauner about this in

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589

What happens in the clone() syscall in the kernel is that the size
gets added to the initial pointer on normal architectures (parisc and ia64
being the exceptions). If you already have the stack pointer, I think you can
just pass size=0 as we do internally in the kernel.

If there was a port of musl to one of the architectures that does it
differently,
then changing callers such as

        pid = __clone(child, stack+sizeof stack,
                CLONE_VM|CLONE_VFORK|SIGCHLD, &args);

would be required, and the separate size argument in clone3() could
help keep that hidden from musl.

         Arnd

  reply	other threads:[~2022-04-08  6:47 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
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 [this message]
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=CAK8P3a17Mrqr36Typ1F_pCUEFjG5PLQ+xrDmDdSB2M0GGK8qfw@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=brauner@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).