All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions 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
  -- strict thread matches above, loose matches on Subject: below --
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.