From: josh@joshtriplett.org
To: "Bird, Tim" <Tim.Bird@sonymobile.com>
Cc: Sarah Sharp <sarah@minilop.net>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
Julia Lawall <julia.lawall@lip6.fr>,
Darren Hart <darren@dvhart.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions
Date: Fri, 9 May 2014 10:23:36 -0700 [thread overview]
Message-ID: <20140509172336.GE8289@cloud> (raw)
In-Reply-To: <F5184659D418E34EA12B1903EE5EF5FDEE1B9D0114@seldmbx02.corpusers.net>
On Fri, May 09, 2014 at 06:59:16PM +0200, Bird, Tim wrote:
> On Friday, May 09, 2014 9:22 AM Josh Triplett wrote:
> >
> > On Fri, May 02, 2014 at 01:11:03PM -0400, Dave Jones wrote:
> > > - how much configurability here is too much ?
> > > r_f_p was an obvious candidate because it's.. well, nasty. Some of the
> > > more straightforward syscalls may not be such a big deal, but then we
> > > have CONFIG's for kcmp and other 'simple' syscalls already..
> >
> > We need a more systematic mechanism, I think. CONFIG_SYSCALL_FOO for
> > every possible FOO seems too much, even for classes of syscalls.
> > Ideally, we could feed in a table of syscalls collected by some
> > analysis of the target userspace, and the kernel will then have exactly
> > those syscalls.
>
> In my system, I set it up so that every syscall had it's own
> SYSCALL_DEFINE macro. and then used a single header file
> consisting of lines like:
> #define syscall_setreuid16_unused 1
>
> The SYSCALL_DEFINE macros would then control whether the
> syscall was extern'ed or not. A separate mechanism converted
> the CALL macro in calls.S (on ARM) to use sys_ni_syscall, and
> LTO made the (now unreferenced) function evaporate.
>
> Overall, this allowed control of every syscall with a single easily
> generated (or easily hand-edited) header file. And, with a stub
> header file, everything worked as without the changes.
>
> The header file was auto-generated by tools that scanned the
> user-space programs for all possible syscall sequences.
>
> In hindsight this system could probably be improved with some
> extra tweaking to the base SYSCALL_DEFINE macros, to make
> it so no source changes were required at the function definition sites.
Another possibility: make all the syscall functions garbage-collectable,
and only keep those referenced from the actual syscall table. Then
generate the syscall table accordingly.
- Josh Triplett
next prev parent reply other threads:[~2014-05-09 17:23 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 16:44 Josh Triplett
2014-05-02 17:11 ` Dave Jones
2014-05-02 17:20 ` James Bottomley
2014-05-02 17:33 ` Dave Jones
2014-05-02 17:46 ` Josh Boyer
2014-05-02 18:50 ` H. Peter Anvin
2014-05-02 19:02 ` Josh Boyer
2014-05-02 19:03 ` Michael Kerrisk (man-pages)
2014-05-02 19:33 ` Theodore Ts'o
2014-05-02 19:38 ` Jiri Kosina
2014-05-02 19:49 ` Dave Jones
2014-05-02 20:06 ` Steven Rostedt
2014-05-02 20:41 ` Theodore Ts'o
2014-05-02 21:01 ` Dave Jones
2014-05-02 21:19 ` Josh Boyer
2014-05-02 21:23 ` Jiri Kosina
2014-05-02 21:36 ` Josh Boyer
2014-05-02 21:27 ` James Bottomley
2014-05-02 21:39 ` Josh Boyer
2014-05-02 22:35 ` Andy Lutomirski
2014-05-06 17:18 ` josh
2014-05-06 17:31 ` Andy Lutomirski
2014-05-09 18:22 ` H. Peter Anvin
2014-05-09 20:37 ` Andy Lutomirski
2014-05-09 22:50 ` Josh Triplett
2014-05-10 0:23 ` James Bottomley
2014-05-10 0:38 ` Andy Lutomirski
2014-05-10 3:44 ` Josh Triplett
2014-05-03 17:30 ` James Bottomley
2014-05-02 21:56 ` tytso
2014-05-02 20:45 ` Ben Hutchings
2014-05-02 21:03 ` Dave Jones
2014-05-03 13:37 ` Michael Kerrisk (man-pages)
2014-05-03 13:35 ` Michael Kerrisk (man-pages)
2014-05-03 13:32 ` Michael Kerrisk (man-pages)
2014-05-02 19:03 ` Mark Brown
2014-05-02 19:45 ` Luck, Tony
2014-05-02 21:03 ` Mark Brown
2014-05-02 21:08 ` Dave Jones
2014-05-02 21:14 ` Andy Lutomirski
2014-05-02 21:21 ` Luck, Tony
2014-05-02 21:38 ` H. Peter Anvin
2014-05-03 1:21 ` Mark Brown
2014-05-07 12:35 ` David Woodhouse
2014-05-09 15:51 ` Mark Brown
2014-05-02 17:33 ` Guenter Roeck
2014-05-02 17:44 ` Steven Rostedt
2014-05-07 11:32 ` David Woodhouse
2014-05-07 16:38 ` James Bottomley
2014-05-02 22:04 ` Jan Kara
2014-05-05 23:45 ` Bird, Tim
2014-05-06 2:14 ` H. Peter Anvin
2014-05-09 16:22 ` Josh Triplett
2014-05-09 16:59 ` Bird, Tim
2014-05-09 17:23 ` josh [this message]
2014-05-08 15:52 ` Christoph Lameter
2014-05-12 17:35 ` Wolfram Sang
2014-05-13 16:36 ` Bird, Tim
2014-05-13 18:00 ` josh
2014-05-14 1:04 ` Julia Lawall
2014-08-17 9:45 ` [Ksummit-discuss] tiny.wiki.kernel.org Josh Triplett
2014-05-08 16:24 [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions Christoph Lameter
2014-05-09 0:31 ` James Bottomley
2014-05-09 14:48 ` Christoph Lameter
2014-05-09 16:24 ` Steven Rostedt
2014-05-09 16:55 ` Christoph Lameter
2014-05-09 17:21 ` josh
2014-05-09 17:42 ` James Bottomley
2014-05-09 17:52 ` Christoph Lameter
2014-05-09 18:32 ` Steven Rostedt
2014-05-09 19:02 ` Julia Lawall
2014-05-09 20:31 ` Steven Rostedt
2014-05-09 17:52 ` Matthew Wilcox
2014-05-12 18:06 ` Dave Hansen
2014-05-12 20:20 ` Roland Dreier
2014-05-14 2:37 ` Li Zefan
2014-05-15 19:41 ` H. Peter Anvin
2014-05-15 20:00 ` Greg KH
2014-05-15 20:29 ` Guenter Roeck
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=20140509172336.GE8289@cloud \
--to=josh@joshtriplett.org \
--cc=Tim.Bird@sonymobile.com \
--cc=dan.carpenter@oracle.com \
--cc=darren@dvhart.com \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@lip6.fr \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=sarah@minilop.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox