Date: Mon, 21 Apr 2014 20:03:21 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Changes for no-legacy-syscalls archs 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@...c.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
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.