From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 0FA9DAF1 for ; Fri, 9 May 2014 17:23:41 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A8FC20340 for ; Fri, 9 May 2014 17:23:40 +0000 (UTC) Date: Fri, 9 May 2014 10:23:36 -0700 From: josh@joshtriplett.org To: "Bird, Tim" Message-ID: <20140509172336.GE8289@cloud> References: <20140502164438.GA1423@jtriplet-mobl1> <20140502171103.GA725@redhat.com> <20140509162229.GB4152@thin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Sarah Sharp , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH , Julia Lawall , Darren Hart , Dan Carpenter Subject: Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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