[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120902170220.GD27715@brightrain.aerifal.cx>
Date: Sun, 2 Sep 2012 13:02:20 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Syscall cleanup?
Hi all,
I just committed the inline/__inline patch resolving the issue with
syscall.h, but I'd like to reconsider some issues with syscall.h. The
whole inline issue arose from having inline asm for syscalls that gets
exposed in the public syscall.h header. To me this seems both
gratuitously incompatible with non-GNUC compilers, and gratuitously
dependent on the __syscall_ret function in musl which was never really
intended to be exposed as a public interface.
What I'd like to consider doing is:
1. Have the public syscall.h only expose __NR_* and SYS_* macros and
the variadic long syscall(long, ...) function, possibly even
eliminating the remapping of legacy syscalls to their 64-bit variants,
etc.
2. To achieve this, keeping only the syscall number definitions in
bits/syscall.h and moving the __SYSCALL_LL_* macros and inline syscall
functions to an internal arch-specific header, and if we want to
remove the legacy/64-bit remapping from the public header, putting
this remapping in the private arch-level header.
I think this approach is arguably cleaner (but some people might
disagree), and would probably stand up better against applications
doing stupid things (like assuming syscall() is a function rather than
a variadic macro).
Opinions?
Rich
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.
