[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140422000321.GK26358@brightrain.aerifal.cx>
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.
