mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Changes for no-legacy-syscalls archs
Date: Mon, 21 Apr 2014 19:13:32 -0400	[thread overview]
Message-ID: <20140421231332.GA7115@brightrain.aerifal.cx> (raw)

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


             reply	other threads:[~2014-04-21 23:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 23:13 Rich Felker [this message]
2014-04-21 23:38 ` Josiah Worcester
2014-04-22  0:03   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140421231332.GA7115@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).