mailing list of musl libc
 help / color / mirror / code / Atom feed
* Re: [musl] Re: add loongarch64 port
@ 2022-03-31  6:20 王洪亮
  2022-03-31  8:14 ` Arnd Bergmann
  2022-03-31 18:47 ` Rich Felker
  0 siblings, 2 replies; 42+ messages in thread
From: 王洪亮 @ 2022-03-31  6:20 UTC (permalink / raw)
  To: musl

在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> Hi,
>>
>> we have published 0001-add-loongarch64-port-v2.patch in
>>
>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>
>> The patch v2 fixed the issues pointed out in v1.
>>
>> have any other issues to modify?
> I see you still refer to the system calls that I asked to be removed from
> the kernel: clone() and the old stat() family (pre-statx). Please use
> only the system calls that are actually supported in mainline kernels,
> otherwise it does not work.
Hi,  Arnd

I understand the new system call is clone3() ?

I found musl does not support the clone3() call now, I can implement the

clone3() in LoongArch for future called.


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


> 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.


Hongliang Wang.


>
>          Arnd


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-31  6:20 [musl] Re: add loongarch64 port 王洪亮
@ 2022-03-31  8:14 ` Arnd Bergmann
  2022-04-01  7:40   ` 王洪亮
  2022-04-27  1:58   ` 王洪亮
  2022-03-31 18:47 ` Rich Felker
  1 sibling, 2 replies; 42+ messages in thread
From: Arnd Bergmann @ 2022-03-31  8:14 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-31  6:20 [musl] Re: add loongarch64 port 王洪亮
  2022-03-31  8:14 ` Arnd Bergmann
@ 2022-03-31 18:47 ` Rich Felker
  2022-04-02  7:59   ` 王洪亮
  1 sibling, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-03-31 18:47 UTC (permalink / raw)
  To: 王洪亮; +Cc: musl

On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> >On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >>Hi,
> >>
> >>we have published 0001-add-loongarch64-port-v2.patch in
> >>
> >>https://github.com/loongson/musl/tree/loongarch-v1.0.
> >>
> >>The patch v2 fixed the issues pointed out in v1.
> >>
> >>have any other issues to modify?
> >I see you still refer to the system calls that I asked to be removed from
> >the kernel: clone() and the old stat() family (pre-statx). Please use
> >only the system calls that are actually supported in mainline kernels,
> >otherwise it does not work.
> Hi,  Arnd
> 
> I understand the new system call is clone3() ?
> 
> I found musl does not support the clone3() call now, I can implement the
> 
> clone3() in LoongArch for future called.

The point isn't that there should be a clone3() function (there
shouldn't) but that __clone has to be implemented by making the
__NR_clone3 syscall not the (nonexistant) __NR_clone syscall.

> 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
> 
> 
> >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,

I don't think we have generics for all of these yet, and what some of
them should be is not clear -- for example, generic kstat should
probably match the statx structure on 32-bit archs. I actually need to
figure some of this out as part of merging the rv32 port. So, for now,
it's probably ok for the loongarch64 port to keep its own copies of
the ones that don't yet have generics, and leave deduplication as
separate task to be done later.

However, for struct stat (musl userspace), I think it would be nice to
use a definition that matches the intended "generic" one (the one
riscv64 and aarch64 use).

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-31  8:14 ` Arnd Bergmann
@ 2022-04-01  7:40   ` 王洪亮
  2022-04-01  7:48     ` Arnd Bergmann
  2022-04-27  1:58   ` 王洪亮
  1 sibling, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-01  7:40 UTC (permalink / raw)
  To: musl


在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> 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

Hi, Arnd


In kernel port, loongarch64 use the generic struct stat.

loongarch64 define struct stat and kstat in musl is consistent with

generic stat in kernel.


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-01  7:40   ` 王洪亮
@ 2022-04-01  7:48     ` Arnd Bergmann
  2022-04-02  6:19       ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-01  7:48 UTC (permalink / raw)
  To: musl

On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>
> In kernel port, loongarch64 use the generic struct stat.
>
> loongarch64 define struct stat and kstat in musl is consistent with
>
> generic stat in kernel.

My point was that I asked for these to be removed in

https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/

With __NR_newfstatat and __NR_fstat gone from the system
call list, there is no 'struct stat' that is exposed by the kernel.

       Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-01  7:48     ` Arnd Bergmann
@ 2022-04-02  6:19       ` 王洪亮
  2022-04-02  7:21         ` Rich Felker
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-02  6:19 UTC (permalink / raw)
  To: musl

Hi, Arnd

I found it has not been removed from system call list in kernel yet.
I wonder if I could keep consistent with the current status of the kernel
for the time being,and modify as the kernel changes.


Hongliang Wang


在 2022/4/1 下午3:48, Arnd Bergmann 写道:
> On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>>
>> In kernel port, loongarch64 use the generic struct stat.
>>
>> loongarch64 define struct stat and kstat in musl is consistent with
>>
>> generic stat in kernel.
> My point was that I asked for these to be removed in
>
> https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
>
> With __NR_newfstatat and __NR_fstat gone from the system
> call list, there is no 'struct stat' that is exposed by the kernel.
>
>         Arnd


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-02  6:19       ` 王洪亮
@ 2022-04-02  7:21         ` Rich Felker
  2022-04-02  9:53           ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-02  7:21 UTC (permalink / raw)
  To: 王洪亮; +Cc: musl

On Sat, Apr 02, 2022 at 02:19:44PM +0800, 王洪亮 wrote:
> Hi, Arnd
> 
> I found it has not been removed from system call list in kernel yet.
> I wonder if I could keep consistent with the current status of the kernel
> for the time being,and modify as the kernel changes.

As I understand it, no -- musl targets the permanent kernel syscall
API/ABI for the arch. So if the legacy stat syscall is not going to be
part of the interface that's approved upstream in the kernel for this
arch, musl can't be using it.

Am I correct in understanding that the syscall & struct stat that are
"there now" are part of a proposed port that's not yet upstream, and
that upstream maintainers are asking for them to be removed as part of
accepting the port?


> 在 2022/4/1 下午3:48, Arnd Bergmann 写道:
> >On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >>在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> >>
> >>In kernel port, loongarch64 use the generic struct stat.
> >>
> >>loongarch64 define struct stat and kstat in musl is consistent with
> >>
> >>generic stat in kernel.
> >My point was that I asked for these to be removed in
> >
> >https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
> >
> >With __NR_newfstatat and __NR_fstat gone from the system
> >call list, there is no 'struct stat' that is exposed by the kernel.
> >
> >        Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-31 18:47 ` Rich Felker
@ 2022-04-02  7:59   ` 王洪亮
  2022-04-06  2:08     ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-02  7:59 UTC (permalink / raw)
  To: musl


在 2022/4/1 上午2:47, Rich Felker 写道:
> On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>> Hi,
>>>>
>>>> we have published 0001-add-loongarch64-port-v2.patch in
>>>>
>>>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>>>
>>>> The patch v2 fixed the issues pointed out in v1.
>>>>
>>>> have any other issues to modify?
>>> I see you still refer to the system calls that I asked to be removed from
>>> the kernel: clone() and the old stat() family (pre-statx). Please use
>>> only the system calls that are actually supported in mainline kernels,
>>> otherwise it does not work.
>> Hi,  Arnd
>>
>> I understand the new system call is clone3() ?
>>
>> I found musl does not support the clone3() call now, I can implement the
>>
>> clone3() in LoongArch for future called.
> The point isn't that there should be a clone3() function (there
> shouldn't) but that __clone has to be implemented by making the
> __NR_clone3 syscall not the (nonexistant) __NR_clone syscall.
> Rich


Hi, Rich


I understand the meaning is that keep the architecture-independent code
and the __clone input parameter unchanged,within the __clone, convert
input parameter to clone3 parameter, and then __NR_clone3 syscall.

will that confusion between clone and clone3?


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-02  7:21         ` Rich Felker
@ 2022-04-02  9:53           ` 王洪亮
  0 siblings, 0 replies; 42+ messages in thread
From: 王洪亮 @ 2022-04-02  9:53 UTC (permalink / raw)
  To: musl


在 2022/4/2 下午3:21, Rich Felker 写道:
> On Sat, Apr 02, 2022 at 02:19:44PM +0800, 王洪亮 wrote:
>> Hi, Arnd
>>
>> I found it has not been removed from system call list in kernel yet.
>> I wonder if I could keep consistent with the current status of the kernel
>> for the time being,and modify as the kernel changes.
> As I understand it, no -- musl targets the permanent kernel syscall
> API/ABI for the arch. So if the legacy stat syscall is not going to be
> part of the interface that's approved upstream in the kernel for this
> arch, musl can't be using it.
>
> Am I correct in understanding that the syscall & struct stat that are
> "there now" are part of a proposed port that's not yet upstream, and
> that upstream maintainers are asking for them to be removed as part of
> accepting the port?
>
Hi, Rich


yes, but it has not been removed from kernel port yet,the Author hopes
to keep it,so I consider modify it when the issue comes to a conclusion.


Hongliang Wang


>> 在 2022/4/1 下午3:48, Arnd Bergmann 写道:
>>> On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
>>>>
>>>> In kernel port, loongarch64 use the generic struct stat.
>>>>
>>>> loongarch64 define struct stat and kstat in musl is consistent with
>>>>
>>>> generic stat in kernel.
>>> My point was that I asked for these to be removed in
>>>
>>> https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/
>>>
>>> With __NR_newfstatat and __NR_fstat gone from the system
>>> call list, there is no 'struct stat' that is exposed by the kernel.
>>>
>>>         Arnd


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-02  7:59   ` 王洪亮
@ 2022-04-06  2:08     ` 王洪亮
  2022-04-06 16:00       ` Markus Wichmann
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-06  2:08 UTC (permalink / raw)
  To: musl


在 2022/4/2 下午3:59, 王洪亮 写道:
>
> 在 2022/4/1 上午2:47, Rich Felker 写道:
>> On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
>>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> we have published 0001-add-loongarch64-port-v2.patch in
>>>>>
>>>>> https://github.com/loongson/musl/tree/loongarch-v1.0.
>>>>>
>>>>> The patch v2 fixed the issues pointed out in v1.
>>>>>
>>>>> have any other issues to modify?
>>>> I see you still refer to the system calls that I asked to be 
>>>> removed from
>>>> the kernel: clone() and the old stat() family (pre-statx). Please use
>>>> only the system calls that are actually supported in mainline kernels,
>>>> otherwise it does not work.
>>> Hi,  Arnd
>>>
>>> I understand the new system call is clone3() ?
>>>
>>> I found musl does not support the clone3() call now, I can implement 
>>> the
>>>
>>> clone3() in LoongArch for future called.
>> The point isn't that there should be a clone3() function (there
>> shouldn't) but that __clone has to be implemented by making the
>> __NR_clone3 syscall not the (nonexistant) __NR_clone syscall.
>> Rich
>
>
> Hi, Rich
>
>
> I understand the meaning is that keep the architecture-independent code
> and the __clone input parameter unchanged,within the __clone, convert
> input parameter to clone3 parameter, and then __NR_clone3 syscall.
>
> will that confusion between clone and clone3?
>
>
> Hongliang Wang


Hi, Rich


within __clone() implement __NR_clone3 syscall,

will that confusion between clone and clone3?


Hongliang Wang




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-06  2:08     ` 王洪亮
@ 2022-04-06 16:00       ` Markus Wichmann
  2022-04-08  2:21         ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Markus Wichmann @ 2022-04-06 16:00 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-06 16:00       ` Markus Wichmann
@ 2022-04-08  2:21         ` 王洪亮
  2022-04-08  6:46           ` Arnd Bergmann
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-08  2:21 UTC (permalink / raw)
  To: musl


在 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?


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-08  2:21         ` 王洪亮
@ 2022-04-08  6:46           ` Arnd Bergmann
  2022-04-09  3:54             ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-08  6:46 UTC (permalink / raw)
  To: musl, Christian Brauner

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

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-08  6:46           ` Arnd Bergmann
@ 2022-04-09  3:54             ` 王洪亮
  2022-04-09 11:06               ` Arnd Bergmann
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-09  3:54 UTC (permalink / raw)
  To: musl


在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> 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


In LoongArch,the stack is grows down.

As previous suggested,I implement __NR_clone3 syscall within __clone()
in loongarch port,based on __clone() interface unchanged and the
architecture-independent code of call __clone() unchanged.

In __NR_clone3 syscall,I need pass the lowest address of memory area to
clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
must not be 0)
         if (kargs->stack_size == 0)
             return false;

current,the __clone()'s input parameters have no "stack_size",so I can't
pass valid(must be size!=0) stack_size to clone3.

your meaning is pass stack_size=0 when the input parameter "stack" of 
__clone()
is already stack point? but pass stack_size=0 is illegal.


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09  3:54             ` 王洪亮
@ 2022-04-09 11:06               ` Arnd Bergmann
  2022-04-09 13:19                 ` Rich Felker
  2022-04-11  3:40                 ` 王洪亮
  0 siblings, 2 replies; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-09 11:06 UTC (permalink / raw)
  To: musl, Christian Brauner

On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> >
> > 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
>
>
> In LoongArch,the stack is grows down.
>
> As previous suggested,I implement __NR_clone3 syscall within __clone()
> in loongarch port,based on __clone() interface unchanged and the
> architecture-independent code of call __clone() unchanged.
>
> In __NR_clone3 syscall,I need pass the lowest address of memory area to
> clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> must not be 0)
>          if (kargs->stack_size == 0)
>              return false;
>
> current,the __clone()'s input parameters have no "stack_size",so I can't
> pass valid(must be size!=0) stack_size to clone3.
>
> your meaning is pass stack_size=0 when the input parameter "stack" of
> __clone()
> is already stack point? but pass stack_size=0 is illegal.

Ah, you are right, that doesn't work at the moment. You dropped Christian
from the Cc list, adding him back because he probably has an idea
for how to address that.

It looks like it could be fixed for the internal callers of __clone() by
adding a __clone3() call that takes the size argument, and falls back
to calling __clone() on architectures that have that. I don't see how
one would do it for the generic clone() library function call though.

         Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09 11:06               ` Arnd Bergmann
@ 2022-04-09 13:19                 ` Rich Felker
  2022-04-09 13:30                   ` Rich Felker
  2022-04-13  7:19                   ` Christian Brauner
  2022-04-11  3:40                 ` 王洪亮
  1 sibling, 2 replies; 42+ messages in thread
From: Rich Felker @ 2022-04-09 13:19 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl, Christian Brauner

On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > >
> > > 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
> >
> >
> > In LoongArch,the stack is grows down.
> >
> > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > in loongarch port,based on __clone() interface unchanged and the
> > architecture-independent code of call __clone() unchanged.
> >
> > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > must not be 0)
> >          if (kargs->stack_size == 0)
> >              return false;
> >
> > current,the __clone()'s input parameters have no "stack_size",so I can't
> > pass valid(must be size!=0) stack_size to clone3.
> >
> > your meaning is pass stack_size=0 when the input parameter "stack" of
> > __clone()
> > is already stack point? but pass stack_size=0 is illegal.
> 
> Ah, you are right, that doesn't work at the moment. You dropped Christian
> from the Cc list, adding him back because he probably has an idea
> for how to address that.
> 
> It looks like it could be fixed for the internal callers of __clone() by
> adding a __clone3() call that takes the size argument, and falls back
> to calling __clone() on architectures that have that. I don't see how
> one would do it for the generic clone() library function call though.

size=4k and passing stack-4k? O_o

This seems like a ridiculous kernel regression to require a size when
none may be available...

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09 13:19                 ` Rich Felker
@ 2022-04-09 13:30                   ` Rich Felker
  2022-04-10 10:30                     ` Arnd Bergmann
  2022-04-13  7:19                   ` Christian Brauner
  1 sibling, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-09 13:30 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl, Christian Brauner

On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > >
> > > > 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
> > >
> > >
> > > In LoongArch,the stack is grows down.
> > >
> > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > in loongarch port,based on __clone() interface unchanged and the
> > > architecture-independent code of call __clone() unchanged.
> > >
> > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > must not be 0)
> > >          if (kargs->stack_size == 0)
> > >              return false;
> > >
> > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > pass valid(must be size!=0) stack_size to clone3.
> > >
> > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > __clone()
> > > is already stack point? but pass stack_size=0 is illegal.
> > 
> > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > from the Cc list, adding him back because he probably has an idea
> > for how to address that.
> > 
> > It looks like it could be fixed for the internal callers of __clone() by
> > adding a __clone3() call that takes the size argument, and falls back
> > to calling __clone() on architectures that have that. I don't see how
> > one would do it for the generic clone() library function call though.
> 
> size=4k and passing stack-4k? O_o
> 
> This seems like a ridiculous kernel regression to require a size when
> none may be available...

Actually, if there aren't yet archs lacking SYS_clone, this API
regression may be a good argument not to drop SYS_clone on new archs
yet until there's a way for new archs to get the same behavior
(unspecified stack size).

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09 13:30                   ` Rich Felker
@ 2022-04-10 10:30                     ` Arnd Bergmann
  2022-04-10 15:26                       ` Rich Felker
  2022-04-13  7:26                       ` Christian Brauner
  0 siblings, 2 replies; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-10 10:30 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner

On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>
> Actually, if there aren't yet archs lacking SYS_clone, this API
> regression may be a good argument not to drop SYS_clone on new archs
> yet until there's a way for new archs to get the same behavior
> (unspecified stack size).

That is a good point, but it also appears that the behavior of
clone3() is unintentional
here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
additional features.

Not sure what the best fix for this is, as the check for size==0 was clearly
intentional, but seems to prevent this from working. A special flag to ignore
the size, or a magic size value like -1ull might work, but neither of them
is a great interface.

        Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-10 10:30                     ` Arnd Bergmann
@ 2022-04-10 15:26                       ` Rich Felker
  2022-04-11  8:03                         ` Arnd Bergmann
  2022-04-13  7:26                       ` Christian Brauner
  1 sibling, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-10 15:26 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl, Christian Brauner

On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> >
> > Actually, if there aren't yet archs lacking SYS_clone, this API
> > regression may be a good argument not to drop SYS_clone on new archs
> > yet until there's a way for new archs to get the same behavior
> > (unspecified stack size).
> 
> That is a good point, but it also appears that the behavior of
> clone3() is unintentional
> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> additional features.
> 
> Not sure what the best fix for this is, as the check for size==0 was clearly
> intentional, but seems to prevent this from working. A special flag to ignore
> the size, or a magic size value like -1ull might work, but neither of them
> is a great interface.

Are there archs already affected, or will this one be the first?

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09 11:06               ` Arnd Bergmann
  2022-04-09 13:19                 ` Rich Felker
@ 2022-04-11  3:40                 ` 王洪亮
  1 sibling, 0 replies; 42+ messages in thread
From: 王洪亮 @ 2022-04-11  3:40 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner


在 2022/4/9 下午7:06, Arnd Bergmann 写道:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
>>> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>>>
>>> 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
>>
>> In LoongArch,the stack is grows down.
>>
>> As previous suggested,I implement __NR_clone3 syscall within __clone()
>> in loongarch port,based on __clone() interface unchanged and the
>> architecture-independent code of call __clone() unchanged.
>>
>> In __NR_clone3 syscall,I need pass the lowest address of memory area to
>> clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
>> must not be 0)
>>           if (kargs->stack_size == 0)
>>               return false;
>>
>> current,the __clone()'s input parameters have no "stack_size",so I can't
>> pass valid(must be size!=0) stack_size to clone3.
>>
>> your meaning is pass stack_size=0 when the input parameter "stack" of
>> __clone()
>> is already stack point? but pass stack_size=0 is illegal.
> Ah, you are right, that doesn't work at the moment. You dropped Christian
> from the Cc list, adding him back because he probably has an idea
> for how to address that.
>
> It looks like it could be fixed for the internal callers of __clone() by
> adding a __clone3() call that takes the size argument, and falls back
> to calling __clone() on architectures that have that. I don't see how
> one would do it for the generic clone() library function call though.
>
>           Arnd


from Christian Brauner's patch in

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

In clone3,the difference is move stack point's setup from userspace to 
kernelspace.
userspace is only responsible for alloc memory area and pass the base 
address of
memory area,kernel is responsible for setup stack point according to the 
direction
the stack's grow.in other words,there is no longer the concept of stack 
in userspace.
so clone3 is incompatible with clone.__NR_clone could not be removed 
from kernel easily,
otherwise the existing user application call clone() is not work.

I understand the case is:
1.In kernel,__NR_clone and __NR_clone3 both support,at least for some time;
2.In libc,__clone() and __clone3() both implement(internal call,glibc 
implement the convert),
clone() and clone3() both export for user.
3.existing application call clone() could work well, new application 
could select to call
clone3().


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-10 15:26                       ` Rich Felker
@ 2022-04-11  8:03                         ` Arnd Bergmann
  2022-04-11 12:11                           ` Rich Felker
  0 siblings, 1 reply; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-11  8:03 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner

On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>
> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > regression may be a good argument not to drop SYS_clone on new archs
> > > yet until there's a way for new archs to get the same behavior
> > > (unspecified stack size).
> >
> > That is a good point, but it also appears that the behavior of
> > clone3() is unintentional
> > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > additional features.
> >
> > Not sure what the best fix for this is, as the check for size==0 was clearly
> > intentional, but seems to prevent this from working. A special flag to ignore
> > the size, or a magic size value like -1ull might work, but neither of them
> > is a great interface.
>
> Are there archs already affected, or will this one be the first?

We have not added any other architectures since clone3 got added,
so this is the first one.

         Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-11  8:03                         ` Arnd Bergmann
@ 2022-04-11 12:11                           ` Rich Felker
  2022-04-11 13:01                             ` Arnd Bergmann
  0 siblings, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-11 12:11 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl, Christian Brauner

On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > yet until there's a way for new archs to get the same behavior
> > > > (unspecified stack size).
> > >
> > > That is a good point, but it also appears that the behavior of
> > > clone3() is unintentional
> > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > additional features.
> > >
> > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > intentional, but seems to prevent this from working. A special flag to ignore
> > > the size, or a magic size value like -1ull might work, but neither of them
> > > is a great interface.
> >
> > Are there archs already affected, or will this one be the first?
> 
> We have not added any other architectures since clone3 got added,
> so this is the first one.

In that case I really think __NR_clone should just be kept for now. It
doesn't really cost anything on the kernel side and it avoids a
dependency on working out how __NR_clone3 is going to fix the missing
functionality.

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-11 12:11                           ` Rich Felker
@ 2022-04-11 13:01                             ` Arnd Bergmann
  2022-04-12  1:11                               ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-11 13:01 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner

On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
> > On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > > >
> > > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > > yet until there's a way for new archs to get the same behavior
> > > > > (unspecified stack size).
> > > >
> > > > That is a good point, but it also appears that the behavior of
> > > > clone3() is unintentional
> > > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > > additional features.
> > > >
> > > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > > intentional, but seems to prevent this from working. A special flag to ignore
> > > > the size, or a magic size value like -1ull might work, but neither of them
> > > > is a great interface.
> > >
> > > Are there archs already affected, or will this one be the first?
> >
> > We have not added any other architectures since clone3 got added,
> > so this is the first one.
>
> In that case I really think __NR_clone should just be kept for now. It
> doesn't really cost anything on the kernel side and it avoids a
> dependency on working out how __NR_clone3 is going to fix the missing
> functionality.

Yes, fair enough.

        Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-11 13:01                             ` Arnd Bergmann
@ 2022-04-12  1:11                               ` 王洪亮
  2022-04-13  1:16                                 ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-12  1:11 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner


在 2022/4/11 下午9:01, Arnd Bergmann 写道:
> On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
>> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
>>> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>>>> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
>>>>> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>>>>>> Actually, if there aren't yet archs lacking SYS_clone, this API
>>>>>> regression may be a good argument not to drop SYS_clone on new archs
>>>>>> yet until there's a way for new archs to get the same behavior
>>>>>> (unspecified stack size).
>>>>> That is a good point, but it also appears that the behavior of
>>>>> clone3() is unintentional
>>>>> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
>>>>> additional features.
>>>>>
>>>>> Not sure what the best fix for this is, as the check for size==0 was clearly
>>>>> intentional, but seems to prevent this from working. A special flag to ignore
>>>>> the size, or a magic size value like -1ull might work, but neither of them
>>>>> is a great interface.
>>>> Are there archs already affected, or will this one be the first?
>>> We have not added any other architectures since clone3 got added,
>>> so this is the first one.
>> In that case I really think __NR_clone should just be kept for now. It
>> doesn't really cost anything on the kernel side and it avoids a
>> dependency on working out how __NR_clone3 is going to fix the missing
>> functionality.
> Yes, fair enough.
>
>          Arnd


Do I need to implement __clone3 for future called in LoongArch port ?


Hongliang Wang.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-12  1:11                               ` 王洪亮
@ 2022-04-13  1:16                                 ` 王洪亮
  0 siblings, 0 replies; 42+ messages in thread
From: 王洪亮 @ 2022-04-13  1:16 UTC (permalink / raw)
  To: musl


在 2022/4/12 上午9:11, 王洪亮 写道:
>
> 在 2022/4/11 下午9:01, Arnd Bergmann 写道:
>> On Mon, Apr 11, 2022 at 2:11 PM Rich Felker <dalias@libc.org> wrote:
>>> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote:
>>>> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker <dalias@libc.org> wrote:
>>>>> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
>>>>>> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
>>>>>>> Actually, if there aren't yet archs lacking SYS_clone, this API
>>>>>>> regression may be a good argument not to drop SYS_clone on new 
>>>>>>> archs
>>>>>>> yet until there's a way for new archs to get the same behavior
>>>>>>> (unspecified stack size).
>>>>>> That is a good point, but it also appears that the behavior of
>>>>>> clone3() is unintentional
>>>>>> here, I'm fairly sure it was meant to be a drop-in replacement 
>>>>>> for clone() with
>>>>>> additional features.
>>>>>>
>>>>>> Not sure what the best fix for this is, as the check for size==0 
>>>>>> was clearly
>>>>>> intentional, but seems to prevent this from working. A special 
>>>>>> flag to ignore
>>>>>> the size, or a magic size value like -1ull might work, but 
>>>>>> neither of them
>>>>>> is a great interface.
>>>>> Are there archs already affected, or will this one be the first?
>>>> We have not added any other architectures since clone3 got added,
>>>> so this is the first one.
>>> In that case I really think __NR_clone should just be kept for now. It
>>> doesn't really cost anything on the kernel side and it avoids a
>>> dependency on working out how __NR_clone3 is going to fix the missing
>>> functionality.
>> Yes, fair enough.
>>
>>          Arnd
>
>
> Do I need to implement __clone3 for future called in LoongArch port ?
>
>
> Hongliang Wang.


Hi,

Have any other issues to modify in LoongArch port ?


Hongliang wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-09 13:19                 ` Rich Felker
  2022-04-09 13:30                   ` Rich Felker
@ 2022-04-13  7:19                   ` Christian Brauner
  2022-04-13 14:06                     ` Rich Felker
  1 sibling, 1 reply; 42+ messages in thread
From: Christian Brauner @ 2022-04-13  7:19 UTC (permalink / raw)
  To: Rich Felker; +Cc: Arnd Bergmann, musl

On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > >
> > > > 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
> > >
> > >
> > > In LoongArch,the stack is grows down.
> > >
> > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > in loongarch port,based on __clone() interface unchanged and the
> > > architecture-independent code of call __clone() unchanged.
> > >
> > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > must not be 0)
> > >          if (kargs->stack_size == 0)
> > >              return false;
> > >
> > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > pass valid(must be size!=0) stack_size to clone3.
> > >
> > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > __clone()
> > > is already stack point? but pass stack_size=0 is illegal.
> > 
> > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > from the Cc list, adding him back because he probably has an idea
> > for how to address that.
> > 
> > It looks like it could be fixed for the internal callers of __clone() by
> > adding a __clone3() call that takes the size argument, and falls back
> > to calling __clone() on architectures that have that. I don't see how
> > one would do it for the generic clone() library function call though.
> 
> size=4k and passing stack-4k? O_o
> 
> This seems like a ridiculous kernel regression to require a size when
> none may be available...

Hm, clone3() is a separate system call. The aim had never been to
provide 1:1 compatibility with legacy clone(). So I fail to see how this
is a regression.

(I'd appreciate if we could stay away from unnecessary qualifiers like
"ridiculous". That doesn't really help the thread in any way.)


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-10 10:30                     ` Arnd Bergmann
  2022-04-10 15:26                       ` Rich Felker
@ 2022-04-13  7:26                       ` Christian Brauner
  2022-04-13  8:26                         ` Arnd Bergmann
  1 sibling, 1 reply; 42+ messages in thread
From: Christian Brauner @ 2022-04-13  7:26 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl

On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> >
> > Actually, if there aren't yet archs lacking SYS_clone, this API
> > regression may be a good argument not to drop SYS_clone on new archs
> > yet until there's a way for new archs to get the same behavior
> > (unspecified stack size).
> 
> That is a good point, but it also appears that the behavior of
> clone3() is unintentional
> here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> additional features.

Mostly but not in all ways. We did decide it's ok to make API
improvements that might break compatibility with legacy clone().

> 
> Not sure what the best fix for this is, as the check for size==0 was clearly
> intentional, but seems to prevent this from working. A special flag to ignore
> the size, or a magic size value like -1ull might work, but neither of them
> is a great interface.

Can someone explain the use-case in a bit more detail, please?

If it is a legitimate use-case that callers need to be able to pass a
stack and have no way of also passing a size then we should just remove
the size == 0 check for all architectures that don't have a hard
requirement on passing a size together with the stack pointer.

Wdyt, Arnd?

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13  7:26                       ` Christian Brauner
@ 2022-04-13  8:26                         ` Arnd Bergmann
  2022-04-13  9:04                           ` Christian Brauner
  0 siblings, 1 reply; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-13  8:26 UTC (permalink / raw)
  To: Christian Brauner; +Cc: musl

On Wed, Apr 13, 2022 at 9:26 AM Christian Brauner <brauner@kernel.org> wrote:
> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > regression may be a good argument not to drop SYS_clone on new archs
> > > yet until there's a way for new archs to get the same behavior
> > > (unspecified stack size).
> >
> > That is a good point, but it also appears that the behavior of
> > clone3() is unintentional
> > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > additional features.
>
> Mostly but not in all ways. We did decide it's ok to make API
> improvements that might break compatibility with legacy clone().

Ok

> >
> > Not sure what the best fix for this is, as the check for size==0 was clearly
> > intentional, but seems to prevent this from working. A special flag to ignore
> > the size, or a magic size value like -1ull might work, but neither of them
> > is a great interface.
>
> Can someone explain the use-case in a bit more detail, please?
>
> If it is a legitimate use-case that callers need to be able to pass a
> stack and have no way of also passing a size then we should just remove
> the size == 0 check for all architectures that don't have a hard
> requirement on passing a size together with the stack pointer.
>
> Wdyt, Arnd?

The normal rule is that we don't define obsolete system calls in new
architectures when an improved variant has been added, e.g. oldoldstat,
oldstat, stat, newstat and stat64 have all been replaced by statx over
the decades. I was expecting the same to be true for clone(), but if
clone3() is not meant as a replacement, we can keep both around.

      Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13  8:26                         ` Arnd Bergmann
@ 2022-04-13  9:04                           ` Christian Brauner
  2022-04-13 13:25                             ` Arnd Bergmann
  0 siblings, 1 reply; 42+ messages in thread
From: Christian Brauner @ 2022-04-13  9:04 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl

On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 9:26 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > Actually, if there aren't yet archs lacking SYS_clone, this API
> > > > regression may be a good argument not to drop SYS_clone on new archs
> > > > yet until there's a way for new archs to get the same behavior
> > > > (unspecified stack size).
> > >
> > > That is a good point, but it also appears that the behavior of
> > > clone3() is unintentional
> > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with
> > > additional features.
> >
> > Mostly but not in all ways. We did decide it's ok to make API
> > improvements that might break compatibility with legacy clone().
> 
> Ok
> 
> > >
> > > Not sure what the best fix for this is, as the check for size==0 was clearly
> > > intentional, but seems to prevent this from working. A special flag to ignore
> > > the size, or a magic size value like -1ull might work, but neither of them
> > > is a great interface.
> >
> > Can someone explain the use-case in a bit more detail, please?
> >
> > If it is a legitimate use-case that callers need to be able to pass a
> > stack and have no way of also passing a size then we should just remove
> > the size == 0 check for all architectures that don't have a hard
> > requirement on passing a size together with the stack pointer.
> >
> > Wdyt, Arnd?
> 
> The normal rule is that we don't define obsolete system calls in new
> architectures when an improved variant has been added, e.g. oldoldstat,
> oldstat, stat, newstat and stat64 have all been replaced by statx over
> the decades. I was expecting the same to be true for clone(), but if
> clone3() is not meant as a replacement, we can keep both around.

No, I agree with you on this and would like to only implement clone3()
on new architectures.

What I'm asking is whether removing the size == 0 check is enough to
unblock the missing behavior and whether you'd be on board with removing
the check?

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  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
  0 siblings, 2 replies; 42+ messages in thread
From: Arnd Bergmann @ 2022-04-13 13:25 UTC (permalink / raw)
  To: Christian Brauner; +Cc: musl

On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> >
> > The normal rule is that we don't define obsolete system calls in new
> > architectures when an improved variant has been added, e.g. oldoldstat,
> > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > the decades. I was expecting the same to be true for clone(), but if
> > clone3() is not meant as a replacement, we can keep both around.
>
> No, I agree with you on this and would like to only implement clone3()
> on new architectures.
>
> What I'm asking is whether removing the size == 0 check is enough to
> unblock the missing behavior and whether you'd be on board with removing
> the check?

I think that's ok here, since we'd only rely on this for loongarch64 at the
moment. It would probably need to be documented in the man page
as a special case though.

        Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13  7:19                   ` Christian Brauner
@ 2022-04-13 14:06                     ` Rich Felker
  0 siblings, 0 replies; 42+ messages in thread
From: Rich Felker @ 2022-04-13 14:06 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Arnd Bergmann, musl

On Wed, Apr 13, 2022 at 09:19:11AM +0200, Christian Brauner wrote:
> On Sat, Apr 09, 2022 at 09:19:39AM -0400, Rich Felker wrote:
> > On Sat, Apr 09, 2022 at 01:06:13PM +0200, Arnd Bergmann wrote:
> > > On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > > 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> > > > > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
> > > > >
> > > > > 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
> > > >
> > > >
> > > > In LoongArch,the stack is grows down.
> > > >
> > > > As previous suggested,I implement __NR_clone3 syscall within __clone()
> > > > in loongarch port,based on __clone() interface unchanged and the
> > > > architecture-independent code of call __clone() unchanged.
> > > >
> > > > In __NR_clone3 syscall,I need pass the lowest address of memory area to
> > > > clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
> > > > must not be 0)
> > > >          if (kargs->stack_size == 0)
> > > >              return false;
> > > >
> > > > current,the __clone()'s input parameters have no "stack_size",so I can't
> > > > pass valid(must be size!=0) stack_size to clone3.
> > > >
> > > > your meaning is pass stack_size=0 when the input parameter "stack" of
> > > > __clone()
> > > > is already stack point? but pass stack_size=0 is illegal.
> > > 
> > > Ah, you are right, that doesn't work at the moment. You dropped Christian
> > > from the Cc list, adding him back because he probably has an idea
> > > for how to address that.
> > > 
> > > It looks like it could be fixed for the internal callers of __clone() by
> > > adding a __clone3() call that takes the size argument, and falls back
> > > to calling __clone() on architectures that have that. I don't see how
> > > one would do it for the generic clone() library function call though.
> > 
> > size=4k and passing stack-4k? O_o
> > 
> > This seems like a ridiculous kernel regression to require a size when
> > none may be available...
> 
> Hm, clone3() is a separate system call. The aim had never been to
> provide 1:1 compatibility with legacy clone(). So I fail to see how this
> is a regression.

It's only a regression if __NR_clone3 is expected to provide a
replacement for __NR_clone where new archs will drop __NR_clone. If
both syscalls will continue to exist then I agree it's not a
regression.

> (I'd appreciate if we could stay away from unnecessary qualifiers like
> "ridiculous". That doesn't really help the thread in any way.)

Fair.

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13 13:25                             ` Arnd Bergmann
@ 2022-04-13 14:09                               ` Rich Felker
  2022-04-14  9:36                                 ` Christian Brauner
  2022-04-14  9:36                               ` Christian Brauner
  1 sibling, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-13 14:09 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: Christian Brauner, musl

On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > >
> > > The normal rule is that we don't define obsolete system calls in new
> > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > the decades. I was expecting the same to be true for clone(), but if
> > > clone3() is not meant as a replacement, we can keep both around.
> >
> > No, I agree with you on this and would like to only implement clone3()
> > on new architectures.
> >
> > What I'm asking is whether removing the size == 0 check is enough to
> > unblock the missing behavior and whether you'd be on board with removing
> > the check?
> 
> I think that's ok here, since we'd only rely on this for loongarch64 at the
> moment. It would probably need to be documented in the man page
> as a special case though.

I'm okay with removing the check for size==0 (so size==0 will be
allowed) and dropping __NR_clone on new archs, as long as it's noted
in comments/documentation that size==0 is explicitly allowed so nobody
breaks this in the future.

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13 13:25                             ` Arnd Bergmann
  2022-04-13 14:09                               ` Rich Felker
@ 2022-04-14  9:36                               ` Christian Brauner
  1 sibling, 0 replies; 42+ messages in thread
From: Christian Brauner @ 2022-04-14  9:36 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: musl

On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > >
> > > The normal rule is that we don't define obsolete system calls in new
> > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > the decades. I was expecting the same to be true for clone(), but if
> > > clone3() is not meant as a replacement, we can keep both around.
> >
> > No, I agree with you on this and would like to only implement clone3()
> > on new architectures.
> >
> > What I'm asking is whether removing the size == 0 check is enough to
> > unblock the missing behavior and whether you'd be on board with removing
> > the check?
> 
> I think that's ok here, since we'd only rely on this for loongarch64 at the
> moment. It would probably need to be documented in the man page
> as a special case though.

Ok, I'll try to have a patch ready early next week since I'm currently
out sick.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-13 14:09                               ` Rich Felker
@ 2022-04-14  9:36                                 ` Christian Brauner
  2022-04-20  9:09                                   ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Christian Brauner @ 2022-04-14  9:36 UTC (permalink / raw)
  To: Rich Felker; +Cc: Arnd Bergmann, musl

On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > >
> > > > The normal rule is that we don't define obsolete system calls in new
> > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > the decades. I was expecting the same to be true for clone(), but if
> > > > clone3() is not meant as a replacement, we can keep both around.
> > >
> > > No, I agree with you on this and would like to only implement clone3()
> > > on new architectures.
> > >
> > > What I'm asking is whether removing the size == 0 check is enough to
> > > unblock the missing behavior and whether you'd be on board with removing
> > > the check?
> > 
> > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > moment. It would probably need to be documented in the man page
> > as a special case though.
> 
> I'm okay with removing the check for size==0 (so size==0 will be
> allowed) and dropping __NR_clone on new archs, as long as it's noted
> in comments/documentation that size==0 is explicitly allowed so nobody
> breaks this in the future.

Ok, I'll try to have a patch ready early next week since I'm currently
out sick.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-14  9:36                                 ` Christian Brauner
@ 2022-04-20  9:09                                   ` 王洪亮
  2022-04-20 13:33                                     ` Christian Brauner
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-20  9:09 UTC (permalink / raw)
  To: musl, Christian Brauner


在 2022/4/14 下午5:36, Christian Brauner 写道:
> On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
>> On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
>>> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
>>>> On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
>>>>> The normal rule is that we don't define obsolete system calls in new
>>>>> architectures when an improved variant has been added, e.g. oldoldstat,
>>>>> oldstat, stat, newstat and stat64 have all been replaced by statx over
>>>>> the decades. I was expecting the same to be true for clone(), but if
>>>>> clone3() is not meant as a replacement, we can keep both around.
>>>> No, I agree with you on this and would like to only implement clone3()
>>>> on new architectures.
>>>>
>>>> What I'm asking is whether removing the size == 0 check is enough to
>>>> unblock the missing behavior and whether you'd be on board with removing
>>>> the check?
>>> I think that's ok here, since we'd only rely on this for loongarch64 at the
>>> moment. It would probably need to be documented in the man page
>>> as a special case though.
>> I'm okay with removing the check for size==0 (so size==0 will be
>> allowed) and dropping __NR_clone on new archs, as long as it's noted
>> in comments/documentation that size==0 is explicitly allowed so nobody
>> breaks this in the future.
> Ok, I'll try to have a patch ready early next week since I'm currently
> out sick.

Hi,

I'm implementing  __NR_clone3 syscall within __clone().

I have another problem:CLONE_DETACHED

in musl,internal call __clone()(such as __pthread_create()),the input 
parameter flags

has been set CLONE_DETACHED ,in kernel,there is a check in 
clone3_args_valid(),

if the condition met,return false.

How to deal with this problem?

src/thread/pthread_create.c:
int __pthread_create(pthread_t *restrict res, const pthread_attr_t 
*restrict attrp,
                                 void *(*entry)(void *), void *restrict arg)
{
     unsigned flags = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND
     | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS
     | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_DETACHED;
     ...
     ret = __clone((c11 ? start_c11 : start), stack, flags, args, 
&new->tid,
                             TP_ADJ(new), &__thread_list_lock);
}

kernel/fork.c:
static bool clone3_args_valid(struct kernel_clone_args *kargs)
{
          /*
           * - make the CLONE_DETACHED bit reusable for clone3
           * - make the CSIGNAL bits reusable for clone3
           */
          if (kargs->flags & (CLONE_DETACHED | CSIGNAL))
                  return false;
}


Hongliang Wang


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-20  9:09                                   ` 王洪亮
@ 2022-04-20 13:33                                     ` Christian Brauner
  2022-04-20 13:54                                       ` Rich Felker
  0 siblings, 1 reply; 42+ messages in thread
From: Christian Brauner @ 2022-04-20 13:33 UTC (permalink / raw)
  To: 王洪亮; +Cc: musl

On Wed, Apr 20, 2022 at 05:09:08PM +0800, 王洪亮 wrote:
> 
> 在 2022/4/14 下午5:36, Christian Brauner 写道:
> > On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> > > On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > > > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > > > > The normal rule is that we don't define obsolete system calls in new
> > > > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > > > the decades. I was expecting the same to be true for clone(), but if
> > > > > > clone3() is not meant as a replacement, we can keep both around.
> > > > > No, I agree with you on this and would like to only implement clone3()
> > > > > on new architectures.
> > > > > 
> > > > > What I'm asking is whether removing the size == 0 check is enough to
> > > > > unblock the missing behavior and whether you'd be on board with removing
> > > > > the check?
> > > > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > > > moment. It would probably need to be documented in the man page
> > > > as a special case though.
> > > I'm okay with removing the check for size==0 (so size==0 will be
> > > allowed) and dropping __NR_clone on new archs, as long as it's noted
> > > in comments/documentation that size==0 is explicitly allowed so nobody
> > > breaks this in the future.
> > Ok, I'll try to have a patch ready early next week since I'm currently
> > out sick.
> 
> Hi,
> 
> I'm implementing  __NR_clone3 syscall within __clone().
> 
> I have another problem:CLONE_DETACHED
> 
> in musl,internal call __clone()(such as __pthread_create()),the input
> parameter flags
> 
> has been set CLONE_DETACHED ,in kernel,there is a check in
> clone3_args_valid(),
> 
> if the condition met,return false.
> 
> How to deal with this problem?

CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
I've documented that in detail under [1] as:

        CLONE_DETACHED (historical)
              For a while (during the Linux 2.5 development series)
              there was a CLONE_DETACHED flag, which caused the parent
              not to receive a signal when the child terminated.
              Ultimately, the effect of this flag was subsumed under the
              CLONE_THREAD flag and by the time Linux 2.6.0 was
              released, this flag had no effect.  Starting in Linux
              2.6.2, the need to give this flag together with
              CLONE_THREAD disappeared.

              This flag is still defined, but it is usually ignored when
              calling clone().  However, see the description of
              CLONE_PIDFD for some exceptions.

[1]: https://man7.org/linux/man-pages/man2/clone.2.html

Would it be possible to drop this flag from musl's pthread_create()
implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)

> 
> src/thread/pthread_create.c:
> int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict
> attrp,
>                                 void *(*entry)(void *), void *restrict arg)
> {
>     unsigned flags = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND
>     | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS
>     | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_DETACHED;
>     ...
>     ret = __clone((c11 ? start_c11 : start), stack, flags, args, &new->tid,
>                             TP_ADJ(new), &__thread_list_lock);
> }
> 
> kernel/fork.c:
> static bool clone3_args_valid(struct kernel_clone_args *kargs)
> {
>          /*
>           * - make the CLONE_DETACHED bit reusable for clone3
>           * - make the CSIGNAL bits reusable for clone3
>           */
>          if (kargs->flags & (CLONE_DETACHED | CSIGNAL))
>                  return false;
> }
> 
> 
> Hongliang Wang
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-20 13:33                                     ` Christian Brauner
@ 2022-04-20 13:54                                       ` Rich Felker
  2022-04-21  6:54                                         ` 王洪亮
  0 siblings, 1 reply; 42+ messages in thread
From: Rich Felker @ 2022-04-20 13:54 UTC (permalink / raw)
  To: Christian Brauner; +Cc: 王洪亮, musl

On Wed, Apr 20, 2022 at 03:33:25PM +0200, Christian Brauner wrote:
> On Wed, Apr 20, 2022 at 05:09:08PM +0800, 王洪亮 wrote:
> > 
> > 在 2022/4/14 下午5:36, Christian Brauner 写道:
> > > On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote:
> > > > On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> > > > > On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > > > > > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > > > > > > The normal rule is that we don't define obsolete system calls in new
> > > > > > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > > > > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > > > > > the decades. I was expecting the same to be true for clone(), but if
> > > > > > > clone3() is not meant as a replacement, we can keep both around.
> > > > > > No, I agree with you on this and would like to only implement clone3()
> > > > > > on new architectures.
> > > > > > 
> > > > > > What I'm asking is whether removing the size == 0 check is enough to
> > > > > > unblock the missing behavior and whether you'd be on board with removing
> > > > > > the check?
> > > > > I think that's ok here, since we'd only rely on this for loongarch64 at the
> > > > > moment. It would probably need to be documented in the man page
> > > > > as a special case though.
> > > > I'm okay with removing the check for size==0 (so size==0 will be
> > > > allowed) and dropping __NR_clone on new archs, as long as it's noted
> > > > in comments/documentation that size==0 is explicitly allowed so nobody
> > > > breaks this in the future.
> > > Ok, I'll try to have a patch ready early next week since I'm currently
> > > out sick.
> > 
> > Hi,
> > 
> > I'm implementing  __NR_clone3 syscall within __clone().
> > 
> > I have another problem:CLONE_DETACHED
> > 
> > in musl,internal call __clone()(such as __pthread_create()),the input
> > parameter flags
> > 
> > has been set CLONE_DETACHED ,in kernel,there is a check in
> > clone3_args_valid(),
> > 
> > if the condition met,return false.
> > 
> > How to deal with this problem?
> 
> CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
> be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
> I've documented that in detail under [1] as:
> 
>         CLONE_DETACHED (historical)
>               For a while (during the Linux 2.5 development series)
>               there was a CLONE_DETACHED flag, which caused the parent
>               not to receive a signal when the child terminated.
>               Ultimately, the effect of this flag was subsumed under the
>               CLONE_THREAD flag and by the time Linux 2.6.0 was
>               released, this flag had no effect.  Starting in Linux
>               2.6.2, the need to give this flag together with
>               CLONE_THREAD disappeared.
> 
>               This flag is still defined, but it is usually ignored when
>               calling clone().  However, see the description of
>               CLONE_PIDFD for some exceptions.
> 
> [1]: https://man7.org/linux/man-pages/man2/clone.2.html
> 
> Would it be possible to drop this flag from musl's pthread_create()
> implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)

I think __clone should just mask it on newer archs. We support Linux
2.6.0 and if lack of CLONE_DETACHED causes bogus signals on 2.6.0 we
should keep it. If it can be established that this doesn't happen and
that CLONE_DETACHED just affected non-thread clones, we can probably
safely drop it.

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-20 13:54                                       ` Rich Felker
@ 2022-04-21  6:54                                         ` 王洪亮
  0 siblings, 0 replies; 42+ messages in thread
From: 王洪亮 @ 2022-04-21  6:54 UTC (permalink / raw)
  To: musl; +Cc: Christian Brauner


在 2022/4/20 下午9:54, Rich Felker 写道
>>> Hi,
>>>
>>> I'm implementing  __NR_clone3 syscall within __clone().
>>>
>>> I have another problem:CLONE_DETACHED
>>>
>>> in musl,internal call __clone()(such as __pthread_create()),the input
>>> parameter flags
>>>
>>> has been set CLONE_DETACHED ,in kernel,there is a check in
>>> clone3_args_valid(),
>>>
>>> if the condition met,return false.
>>>
>>> How to deal with this problem?
>> CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should
>> be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything.
>> I've documented that in detail under [1] as:
>>
>>          CLONE_DETACHED (historical)
>>                For a while (during the Linux 2.5 development series)
>>                there was a CLONE_DETACHED flag, which caused the parent
>>                not to receive a signal when the child terminated.
>>                Ultimately, the effect of this flag was subsumed under the
>>                CLONE_THREAD flag and by the time Linux 2.6.0 was
>>                released, this flag had no effect.  Starting in Linux
>>                2.6.2, the need to give this flag together with
>>                CLONE_THREAD disappeared.
>>
>>                This flag is still defined, but it is usually ignored when
>>                calling clone().  However, see the description of
>>                CLONE_PIDFD for some exceptions.
>>
>> [1]: https://man7.org/linux/man-pages/man2/clone.2.html
>>
>> Would it be possible to drop this flag from musl's pthread_create()
>> implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.)
> I think __clone should just mask it on newer archs. We support Linux
> 2.6.0 and if lack of CLONE_DETACHED causes bogus signals on 2.6.0 we
> should keep it. If it can be established that this doesn't happen and
> that CLONE_DETACHED just affected non-thread clones, we can probably
> safely drop it.
>
> Rich

I have already implemented __NR_clone3 syscall within __clone(),

and libc-test OK.the code is shown below,please help review.


src/thread/loongarch64/clone.s:

#__clone(func, stack, flags, arg, ptid, tls, ctid)

#         a0,    a1,   a2,    a3,  a4,  a5,   a6
# sys_clone3(struct clone_args *cl_args, size_t size)
#                                 a0             a1

.global __clone
.hidden __clone
.type   __clone,@function
__clone:
         # Save function pointer and argument pointer on new thread stack
         addi.d  $a1, $a1, -16
         st.d    $a0, $a1, 0     # save function pointer
         st.d    $a3, $a1, 8     # save argument pointer

         li.d    $t0, ~0x004000ff  # mask CSIGNAL and CLONE_DETACHED
         and     $t1, $a2, $t0     # cl_args.flags
         li.d    $t0, 0x000000ff   # CSIGNAL
         and     $t2, $a2, $t0     # cl_args.exit_signal

         bstrins.d $sp, $zero, 2, 0  # align stack to 8 bytes
         addi.d  $sp, $sp, -88   # struct clone_args
         st.d    $t1, $sp, 0     # flags
         st.d    $a4, $sp, 8     # pidfd
         st.d    $a6, $sp, 16    # child_tid
         st.d    $a4, $sp, 24    # parent_tid
         st.d    $t2, $sp, 32    # exit_signal
         st.d    $a1, $sp, 40    # stack
         st.d    $zero, $sp, 48  # stack_size
         st.d    $a5, $sp, 56    # tls
         st.d    $zero, $sp, 64  # set_tid
         st.d    $zero, $sp, 72  # set_tid_size
         st.d    $zero, $sp, 80  # cgroup

         move    $a0, $sp
         li.d    $a1, 88
         li.d    $a7, 435        # __NR_clone3
         syscall 0               # call clone3

         beqz    $a0, 1f         # whether child process
         addi.d  $sp, $sp, 88
         jirl    $zero, $ra, 0   # parent process return

1:
         ld.d    $t8, $sp, 0     # function pointer
         ld.d    $a0, $sp, 8     # argument pointer
         jirl    $ra, $t8, 0     # call the user's function
         li.d    $a7, 93
         syscall 0               # child process exit


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-31  8:14 ` Arnd Bergmann
  2022-04-01  7:40   ` 王洪亮
@ 2022-04-27  1:58   ` 王洪亮
  2022-04-27  2:13     ` Rich Felker
  1 sibling, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-04-27  1:58 UTC (permalink / raw)
  To: musl


在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> 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.
>
>
>        Arnd

there is a build error if I remove __NR_fstat and __NR_newfstatat,
the architecture-independent code depends on the __NR_fstat and
__NR_fstatat defined in architecture platform.
How to deal with this issue?

In file included from src/stat/fstatat.c:8:
src/stat/fstatat.c: In function ‘fstatat_kstat’:
src/stat/fstatat.c:78:19: error: ‘SYS_fstat’ undeclared (first use in 
this function); did you mean ‘SYS_statx’?
    ret = __syscall(SYS_fstat, fd, &kst);

src/stat/fstatat.c:80:20: error: ‘SYS_fstatat’ undeclared (first use in 
this function); did you mean ‘SYS_fstatfs’?

     ret = __syscall(SYS_fstatat, fd, path, &kst, flag);


Hongliang Wang



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-04-27  1:58   ` 王洪亮
@ 2022-04-27  2:13     ` Rich Felker
  0 siblings, 0 replies; 42+ messages in thread
From: Rich Felker @ 2022-04-27  2:13 UTC (permalink / raw)
  To: 王洪亮; +Cc: musl

On Wed, Apr 27, 2022 at 09:58:44AM +0800, 王洪亮 wrote:
> 
> 在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> >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.
> >
> >
> >       Arnd
> 
> there is a build error if I remove __NR_fstat and __NR_newfstatat,
> the architecture-independent code depends on the __NR_fstat and
> __NR_fstatat defined in architecture platform.
> How to deal with this issue?
> 
> In file included from src/stat/fstatat.c:8:
> src/stat/fstatat.c: In function ‘fstatat_kstat’:
> src/stat/fstatat.c:78:19: error: ‘SYS_fstat’ undeclared (first use
> in this function); did you mean ‘SYS_statx’?
>    ret = __syscall(SYS_fstat, fd, &kst);
> 
> src/stat/fstatat.c:80:20: error: ‘SYS_fstatat’ undeclared (first use
> in this function); did you mean ‘SYS_fstatfs’?
> 
>     ret = __syscall(SYS_fstatat, fd, path, &kst, flag);

There are pending changes that are needed for riscv32 that address
the same issue there. I'll review them again in the next couple days
and either merge them or make alternative changes to make the rest of
musl not assume the existence of these syscalls.

Rich

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [musl] Re: add loongarch64 port
  2022-03-29  8:12 ` [musl] " 王洪亮
@ 2022-03-29  8:26   ` Arnd Bergmann
  0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2022-03-29  8:26 UTC (permalink / raw)
  To: musl

On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>
> Hi,
>
> we have published 0001-add-loongarch64-port-v2.patch in
>
> https://github.com/loongson/musl/tree/loongarch-v1.0.
>
> The patch v2 fixed the issues pointed out in v1.
>
> have any other issues to modify?

I see you still refer to the system calls that I asked to be removed from
the kernel: clone() and the old stat() family (pre-statx). Please use
only the system calls that are actually supported in mainline kernels,
otherwise it does not work.

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.

        Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [musl] Re: add loongarch64 port
  2022-03-22  3:52 [musl] " 王洪亮
@ 2022-03-29  8:12 ` 王洪亮
  2022-03-29  8:26   ` Arnd Bergmann
  0 siblings, 1 reply; 42+ messages in thread
From: 王洪亮 @ 2022-03-29  8:12 UTC (permalink / raw)
  To: musl

Hi,

we have published 0001-add-loongarch64-port-v2.patch in

https://github.com/loongson/musl/tree/loongarch-v1.0.

The patch v2 fixed the issues pointed out in v1.

have any other issues to modify?

Please code review, thanks.


Hongliang Wang


在 2022/3/22 上午11:52, 王洪亮 写道:
> Hi,
>
> Thank you for give us some useful suggestions on the first submit
>
> from 翟小娟 <zhaixiaojuan@loongson.cn>.
>
> we review code and make changes on code specification, code style
>
> and code errors.
>
>
> The new patch has been published in
>
> https://github.com/loongson/musl/tree/loongarch-v1.0.
>
>
> The linux kernel has been published in
>
> https://github.com/loongson/linux/tree/loongarch-next.
>
>
> we alse published gcc, glibc in https://github.com/loongson
>
> and submitting to the community.
>
>
> we can supply a physical machine remote login for test musl.
>
> It has been compiled and run the libc-test successfully.
>
>
> Please code review, thanks!
>
>
> Hongliang Wang
>


^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2022-04-27  2:13 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-31  6:20 [musl] Re: add loongarch64 port 王洪亮
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
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

Code repositories for project(s) associated with this 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).