mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Deduplicating __NR_* and SYS_* syscall defines
Date: Fri, 13 May 2016 12:02:19 -0400	[thread overview]
Message-ID: <20160513160219.GM21636@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160513101548.GE22574@port70.net>

On Fri, May 13, 2016 at 12:15:48PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2016-05-11 20:57:12 -0400]:
> > On Wed, May 11, 2016 at 07:22:30PM -0500, Bobby Bingham wrote:
> > > On Wed, May 11, 2016 at 05:53:12PM -0400, Rich Felker wrote:
> > > > On Mon, May 09, 2016 at 07:26:37PM -0500, Bobby Bingham wrote:
> > > > > During the powerpc64 review, Rich mentioned wanting to replace the
> > > > > arch/*/bits/syscall.h files with .in files that would be preprocessed with
> > > > > something like:
> > > > > 
> > > > >     sed -e p -e s/__NR_/SYS_/ < $< > $@
> > > > > 
> > > > > This would eliminate a lot of intra-file duplication here.
> 
> i don't know how much is it worth to keep the syntax consistent
> with kernel headers, i'd just clean these up with special syntax
> like TYPEDEF in alltypes e.g.
> 
> SYS write 1

This does save some space (maybe 25-30% size reduction?) but I think
it also comes at the sense of some flexibility and readability. For
example if there are ever archs where the definitions need to depend
on some compile-time macros (e.g. if we had an arch where it makes
sense to put a couple ABI variants with different syscalls together as
subarchs rather than independent archs) there becomes a question of
how to format those conditions and whether their directives would be
misinterpreted. Having #define on every line so that the file as-is is
valid preprocessor input avoids any such issues.

Of course these things are also a reason to possibly prefer the form
with SYS_ and __NR_ interleaved (my original sed command). With them
separate like the current proposed patch, anything inside a
conditional block or dependent on interleaved redefinition of other
macros would break.

> with consistent whitespace, removed comments etc.

Agree on consistent whitespace (and we should do that regardless of
the rest of this proposal), but note that it can't necessarily be just
3 space-delimited tokens. Some archs have arithmetic expressions for
the integer field, and requiring that not to contain whitespace would
be rather arbitrary and confusing, so the last field would probably
need to be the whole remainder of the line.

Rich


      reply	other threads:[~2016-05-13 16:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  0:26 Bobby Bingham
2016-05-10  7:34 ` Alexander Monakov
2016-05-10  8:47   ` Alexander Monakov
2016-05-11 21:53 ` Rich Felker
2016-05-12  0:22   ` Bobby Bingham
2016-05-12  0:57     ` Rich Felker
2016-05-12  3:56       ` Bobby Bingham
2016-05-13 10:15       ` Szabolcs Nagy
2016-05-13 16:02         ` Rich Felker [this message]

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=20160513160219.GM21636@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).