Re: [PATCH v2 3/7] syscall.h: add syscall_se t_arguments() and syscall_set_return_value()

"H. Peter Anvin" <[email protected]>
Newsgroups gmane.linux.uml.devel,gmane.comp.sysutils.strace.devel,gmane.linux.kernel.arc,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.hexagon,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.kernel.cross-arch
Message-ID <[email protected]>
On January 17, 2025 7:45:02 AM PST, Eugene Syromyatnikov <[email protected]> wrote:
>On Fri, Jan 17, 2025 at 2:03 AM H. Peter Anvin <[email protected]> wrote:
>>
>> I link the concept of this patchset, but *please* make it clear in the
>> comments that this does not solve the issue of 64-bit kernel arguments
>> on 32-bit systems being ABI specific.
>
>Sorry, but I don't see how this is relevant; each architecture has its
>own ABI with its own set of peculiarities, and there's a lot of
>(completely unrelated) work needed in order to make an ABI that is
>architecture-agnostic.  All this patch set does is provides a
>consistent way to manipulate scno and args across architectures;  it
>doesn't address the fact that some architectures have mmap2/mmap_pgoff
>syscall, or that some have fadvise64_64 in addition to fadvise64, or
>the existence of clone2, or socketcall, or ipc; or that some
>architectures don't have open or stat;  or that scnos on different
>architectures or even different bit-widths within the "same"
>architecture are different.
>
>> This isn't unique to this patch in any way; the only way to handle it is
>> by keeping track of each ABI.
>
>That's true, but this patch doesn't even try to address that.
>

I just want it noted in the comment, that's all.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.