* Changes for no-legacy-syscalls archs @ 2014-04-21 23:13 Rich Felker 2014-04-21 23:38 ` Josiah Worcester 0 siblings, 1 reply; 3+ messages in thread From: Rich Felker @ 2014-04-21 23:13 UTC (permalink / raw) To: musl Based on reports from the in-progress aarch64 port, at least the following syscalls musl uses internally in several places are missing on "new" archs: - open - stat - pipe I'm actually surprised it way so few, but I think that's indicative that our test coverage is insufficient; all of the syscalls with "at" variants or 2/3/4 variants (pipe/dup/accept) should be problems. Anyway, as far as I can tell, of the above three, "open" is the only one used as an inline syscall in multiple places across the source. The others (stat and pipe) are just used via calls to the public function, so any changes needed can be made in just one place. For open, of the 8 uses, 3-4 are in places that need to be namespace-protected (so we can't just call the open function, and anyway it's a cancellation point which is problematic) and one, __init_security, is in a place that's size-critical (linked in all static programs) so we don't want to add a function call there anyway. The rest of the call points are all largish functions where the inline syscall is not making a significant difference to size. So, for all instances except __init_security and open itself, I think it would make sense to call an external __open function. This would also be a nice place to tuck away the O_LARGEFILE flag, rather than having all calling code be aware of it. We could then just add two additional, mildly-ugly #ifdef SYS_open checks to __init_security.c and open.c and be done with it (open itself is special because it has to make a cancellable syscall). Alternatively, instead of the external function __open, we could define a macro __open, or sys_open, or similar, in internal/syscall.h and have it expand to either an inline syscall to SYS_open or SYS_openat depending on whether SYS_open is defined. This would avoid any size increase and would also avoid having an #ifdef in __init_security. The second solution might be preferable; eventually, we could transition to having most/all syscalls be made via sys_* function-like macros in syscall.h, which would facilitate porting to bare-metal without implementing a huge numeric syscall dispatch function like what's in the kernel. Rich ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Changes for no-legacy-syscalls archs 2014-04-21 23:13 Changes for no-legacy-syscalls archs Rich Felker @ 2014-04-21 23:38 ` Josiah Worcester 2014-04-22 0:03 ` Rich Felker 0 siblings, 1 reply; 3+ messages in thread From: Josiah Worcester @ 2014-04-21 23:38 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3309 bytes --] On Mon, Apr 21, 2014 at 6:13 PM, Rich Felker <dalias@libc.org> wrote: > Based on reports from the in-progress aarch64 port, at least the > following syscalls musl uses internally in several places are missing > on "new" archs: > > - open > - stat > - pipe > > I'm actually surprised it way so few, but I think that's indicative > that our test coverage is insufficient; all of the syscalls with "at" > variants or 2/3/4 variants (pipe/dup/accept) should be problems. > The complete list of variants missing from new ports can be seen in include/uapi/asm-generic/unistd.h in the kernel tree, under the __ARCH_WANT_SYSCALL_NO_AT, __ARCH_WANT_SYSCALL_NO_FLAGS, and __ARCH_WANT_SYSCALL_DEPRECATED #ifdefs. As far as I'm aware this should apply to all future Linux archs, as the current Linux development policy is to use arch-generic constants for anything new, rather than the crazy approach of matching some old API. > > Anyway, as far as I can tell, of the above three, "open" is the only > one used as an inline syscall in multiple places across the source. > The others (stat and pipe) are just used via calls to the public > function, so any changes needed can be made in just one place. For > open, of the 8 uses, 3-4 are in places that need to be > namespace-protected (so we can't just call the open function, and > anyway it's a cancellation point which is problematic) and one, > __init_security, is in a place that's size-critical (linked in all > static programs) so we don't want to add a function call there anyway. > The rest of the call points are all largish functions where the inline > syscall is not making a significant difference to size. > > So, for all instances except __init_security and open itself, I think > it would make sense to call an external __open function. This would > also be a nice place to tuck away the O_LARGEFILE flag, rather than > having all calling code be aware of it. We could then just add two > additional, mildly-ugly #ifdef SYS_open checks to __init_security.c > and open.c and be done with it (open itself is special because it has > to make a cancellable syscall). > > Alternatively, instead of the external function __open, we could > define a macro __open, or sys_open, or similar, in internal/syscall.h > and have it expand to either an inline syscall to SYS_open or > SYS_openat depending on whether SYS_open is defined. This would avoid > any size increase and would also avoid having an #ifdef in > __init_security. > > The second solution might be preferable; eventually, we could > transition to having most/all syscalls be made via sys_* function-like > macros in syscall.h, which would facilitate porting to bare-metal > without implementing a huge numeric syscall dispatch function like > what's in the kernel. > I rather like this approach to doing the syscalls, as it does make it notably easier to port musl to environments where the numeric syscall dispatch function is not very nice. However, I would think it'd be preferable to switch to this for all the system calls rather than just have a single sys_open macro. So, for the minimally-invasive approach, I feel that just doing the #ifdef in the two places it's needed is nicer (particularly as it doesn't restrict you from switching to the sys_* macros in the future). > > Rich > [-- Attachment #2: Type: text/html, Size: 4184 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Changes for no-legacy-syscalls archs 2014-04-21 23:38 ` Josiah Worcester @ 2014-04-22 0:03 ` Rich Felker 0 siblings, 0 replies; 3+ messages in thread From: Rich Felker @ 2014-04-22 0:03 UTC (permalink / raw) To: musl On Mon, Apr 21, 2014 at 06:38:12PM -0500, Josiah Worcester wrote: > On Mon, Apr 21, 2014 at 6:13 PM, Rich Felker <dalias@libc.org> wrote: > > > Based on reports from the in-progress aarch64 port, at least the > > following syscalls musl uses internally in several places are missing > > on "new" archs: > > > > - open > > - stat > > - pipe > > > > I'm actually surprised it way so few, but I think that's indicative > > that our test coverage is insufficient; all of the syscalls with "at" > > variants or 2/3/4 variants (pipe/dup/accept) should be problems. > > > > The complete list of variants missing from new ports can be seen in > include/uapi/asm-generic/unistd.h in the kernel tree, under the > __ARCH_WANT_SYSCALL_NO_AT, __ARCH_WANT_SYSCALL_NO_FLAGS, and > __ARCH_WANT_SYSCALL_DEPRECATED #ifdefs. As far as I'm aware this should > apply to all future Linux archs, as the current Linux development policy is > to use arch-generic constants for anything new, rather than the crazy > approach of matching some old API. Thanks. I'll check these. > > Anyway, as far as I can tell, of the above three, "open" is the only > > one used as an inline syscall in multiple places across the source. > > The others (stat and pipe) are just used via calls to the public > > function, so any changes needed can be made in just one place. For > > open, of the 8 uses, 3-4 are in places that need to be > > namespace-protected (so we can't just call the open function, and > > anyway it's a cancellation point which is problematic) and one, > > __init_security, is in a place that's size-critical (linked in all > > static programs) so we don't want to add a function call there anyway. > > The rest of the call points are all largish functions where the inline > > syscall is not making a significant difference to size. > > > > So, for all instances except __init_security and open itself, I think > > it would make sense to call an external __open function. This would > > also be a nice place to tuck away the O_LARGEFILE flag, rather than > > having all calling code be aware of it. We could then just add two > > additional, mildly-ugly #ifdef SYS_open checks to __init_security.c > > and open.c and be done with it (open itself is special because it has > > to make a cancellable syscall). > > > > Alternatively, instead of the external function __open, we could > > define a macro __open, or sys_open, or similar, in internal/syscall.h > > and have it expand to either an inline syscall to SYS_open or > > SYS_openat depending on whether SYS_open is defined. This would avoid > > any size increase and would also avoid having an #ifdef in > > __init_security. > > > > The second solution might be preferable; eventually, we could > > transition to having most/all syscalls be made via sys_* function-like > > macros in syscall.h, which would facilitate porting to bare-metal > > without implementing a huge numeric syscall dispatch function like > > what's in the kernel. > > > > > I rather like this approach to doing the syscalls, as it does make it > notably easier to port musl to environments where the numeric syscall > dispatch function is not very nice. However, I would think it'd be > preferable to switch to this for all the system calls rather than just have > a single sys_open macro. So, for the minimally-invasive approach, I feel > that just doing the #ifdef in the two places it's needed is nicer > (particularly as it doesn't restrict you from switching to the sys_* macros > in the future). Indeed; also switching to the "bare-metal-friendly" system would require a way to make both cancellable and non-cancellable variants of the syscall. However the change is not just #ifdef in two places. It's #ifdef in two places, plus changing all other uses to call an external function __open or similar, which would require either finding a place to put a prototype for it, or duplicating the prototype all over the place (which is error-prone). This is why I kinda like the syscall.h solution anyway: it provides a nice place to put the prototype or macro definition, and we can use a macro rather than an external function and avoid one of the ifdefs (the "__init_security" one that's now in __init_libc since I flattened some code). Basically, the syscall.h approach is both easier/simpler and closer to what we might want to do in the long term. That's why I kinda lean towards it. Rich ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-04-22 0:03 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-21 23:13 Changes for no-legacy-syscalls archs Rich Felker 2014-04-21 23:38 ` Josiah Worcester 2014-04-22 0:03 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).