[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1f6d8cb-da12-0f0a-4929-108497119b8a@loongson.cn>
Date: Sat, 9 Apr 2022 11:54:56 +0800
From: 王洪亮 <wanghongliang@...ngson.cn>
To: musl@...ts.openwall.com
Subject: Re: Re: add loongarch64 port
在 2022/4/8 下午2:46, Arnd Bergmann 写道:
> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@...ngson.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
