Re: [PATCH v2 3/7] syscall.h: add syscall_se t_arguments() and syscall_set_return_value()
"H. Peter Anvin" <[email protected]>
| Newsgroups | org.kernel.vger.linux-hexagon,dev.linux.lists.loongarch,org.infradead.lists.linux-riscv,org.infradead.lists.linux-snps-arc,org.infradead.lists.linux-um,org.kernel.vger.linux-arch,org.kernel.vger.linux-csky,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mips,org.kernel.vger.linux-openrisc,org.kernel.vger.linux-parisc,org.kernel.vger.linux-s390,org.kernel.vger.linux-sh,org.kernel.vger.sparclinux,org.ozlabs.lists.linuxppc-dev |
|---|---|
| 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.