[Resending this mail due to some email encoding brokenness that prevented it from reaching LKML the first time; sorry to anyone who receives two copies.] On Tue, Nov 25, 2014 at 08:17:58AM -0800, Randy Dunlap wrote: > On 11/24/2014 03:00 PM, Pieter Smith wrote: > >REPO: https://github.com/smipi1/linux-tinification.git > > > >BRANCH: tiny/config-syscall-splice > > > >BACKGROUND: This patch-set forms part of the Linux Kernel Tinification effort ( > > https://tiny.wiki.kernel.org/). > > > >GOAL: Support compiling out the splice family of syscalls (splice, vmsplice, > > tee and sendfile) along with all supporting infrastructure if not needed. > > Many embedded systems will not need the splice-family syscalls. Omitting them > > saves space. > > Hi, > > Is the splice family of syscalls the only one that tiny has identified > for optional building or can we expect similar treatment for other > syscalls? Pretty much any system call that you could conceive of writing a userspace without. There's a partial project list at https://tiny.wiki.kernel.org/projects. > Why will many embedded systems not need these syscalls? You know > exactly what apps they run and you are positive that those apps do > not use splice? Yes, precisely. We're talking about embedded systems small enough that you're booting with init=/your/app and don't even call fork(), where you know exactly what code you're putting in and what libraries you use. And they're almost certainly not running glibc. > >RESULTS: A tinyconfig bloat-o-meter score for the entire patch-set: > > > >add/remove: 0/41 grow/shrink: 5/7 up/down: 23/-8422 (-8399) > > The summary is that this patch saves around 8 KB of code space -- > is that correct? Right. For reference, we're talking about kernels where the *total* size is a few hundred kB. > How much storage space do embedded systems have nowadays? For the embedded systems we're targeting for the tinification effort, in a first pass: 512k-2M of storage (often for an *uncompressed* kernel, to support execute-in-place), and 128k-512k of memory. We've successfully built useful kernels and userspaces for such environments, and we'd like to go even smaller. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html