Re: [musl] Re: add loongarch64 port

[Arnd Bergmann <arnd@kernel.org>]

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