[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a06fe615e4790134e29954ab016b6ec11f24d62c.camel@physik.fu-berlin.de>
Date: Sat, 17 Jan 2026 22:23:57 +0100
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Jessica Clarke <jrtc27@...c27.com>, Ludwig Rydberg
<ludwig.rydberg@...sler.com>
Cc: davem@...emloft.net, andreas@...sler.com, brauner@...nel.org,
shuah@...nel.org, sparclinux@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
arnd@...db.de, geert@...ux-m68k.org, schuster.simon@...mens-energy.com
Subject: Re: [PATCH 2/3] sparc: Add architecture support for clone3
Hi,
On Fri, 2026-01-16 at 16:47 +0000, Jessica Clarke wrote:
> On Fri, Jan 16, 2026 at 04:30:50PM +0100, Ludwig Rydberg wrote:
> > Add support for the clone3 system call to the SPARC architectures.
> >
> > The implementation follows the pattern of the original clone syscall.
> > However, instead of explicitly calling kernel_clone, the clone3
> > handler calls the generic sys_clone3 handler in kernel/fork.
> > In case no stack is provided, the parents stack is reused.
> >
> > The return call conventions for clone on SPARC are kept for clone3:
> > Parent --> %o0 == child's pid, %o1 == 0
> > Child --> %o0 == parent's pid, %o1 == 1
>
> One of the benefits of having a new clone3 is that the interface can be
> made the same across all architectures*, unlike clone, which both passes
> the arguments in different orders for different architectures and, in
> the case of SPARC, has this weird return convention inherited from the
> SunOS syscall interface. Is there a good reason to deviate for clone3
> too and keep this annoying oddity going, that requires special-casing
> SPARC when other architectures can just syscall(__NR_clone3, ...)?
Very good point. Since clone3() is a new syscall, I think it would make more
sense to use the same interface as all the other architectures.
The weird syscall interface was already the reason why we had to write custom
code for systemd on SPARC in order to use the raw clone() syscall.
I think the proposed implementation of clone3() for SPARC would actually break
the libcamera build which calls clone3() using the syscall handler [1]:
FAILED: [code=1] src/libcamera/libcamera.so.0.6.0.p/process.cpp.o
c++ -Isrc/libcamera/libcamera.so.0.6.0.p -Isrc/libcamera -I../src/libcamera -Iinclude -I../include -Iinclude/libcamera -Iinclude/libcamera/ipa -Iinclude/libcamera/internal -Isrc/libcamera/proxy -
I/usr/include/p11-kit-1 -I/usr/include/sparc64-linux-gnu -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wnon-virtual-dtor -
Wno-redundant-move -Wmissing-declarations -Wshadow -include /build/reproducible-path/libcamera-0.6.0/obj-sparc64-linux-gnu/config.h -g -O2 -ffile-prefix-map=/build/reproducible-path/libcamera-0.6.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DLIBCAMERA_BASE_PRIVATE -MD -MQ src/libcamera/libcamera.so.0.6.0.p/process.cpp.o -MF
src/libcamera/libcamera.so.0.6.0.p/process.cpp.o.d -o src/libcamera/libcamera.so.0.6.0.p/process.cpp.o -c ../src/libcamera/process.cpp
../src/libcamera/process.cpp: In member function ‘int libcamera::Process::start(const std::string&, libcamera::Span<const std::__cxx11::basic_string<char> >, libcamera::Span<const int>)’:
../src/libcamera/process.cpp:160:33: error: ‘SYS_clone3’ was not declared in this scope; did you mean ‘SYS_clone’?
160 | long childPid = syscall(SYS_clone3, &cargs, sizeof(cargs));
| ^~~~~~~~~~
| SYS_clone
I'll verify that and report back.
Adrian
> [1] https://buildd.debian.org/status/fetch.php?pkg=libcamera&arch=sparc64&ver=0.6.0-2&stamp=1766489678&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Powered by blists - more mailing lists