Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, 25 Nov 2014 14:04:41 -0500 (EST) David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 25 Nov 2014 10:53:10 -0800 > > > It's not a "slippery slope"; it's been our standard practice for ages. > > We've never put an entire class of generic system calls behind > a config option. Try running an original MCC Linux binary and C lib on a current kernel We've put *entire binary formats* behind a config option. We've put older syscalls behind it, we've put sysfs behind it, sysctl behind it, the older microcode interfaces behind it, ISA bus as a concept behind options. VDSO, IPC, even 32bit support ... the list goes on and on. I'd say those were far more generic on the whole than splice/sendfile. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, 25 Nov 2014 14:04:41 -0500 (EST) David Miller da...@davemloft.net wrote: From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. Try running an original MCC Linux binary and C lib on a current kernel We've put *entire binary formats* behind a config option. We've put older syscalls behind it, we've put sysfs behind it, sysctl behind it, the older microcode interfaces behind it, ISA bus as a concept behind options. VDSO, IPC, even 32bit support ... the list goes on and on. I'd say those were far more generic on the whole than splice/sendfile. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
[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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 02:04:41PM -0500, David Miller wrote: > From: j...@joshtriplett.org > Date: Tue, 25 Nov 2014 10:53:10 -0800 > > > It's not a "slippery slope"; it's been our standard practice for ages. > > We've never put an entire class of generic system calls behind > a config option. I would have loved to make them optional individually, but they all are semantic variations of the same thing: Moving data between fd's without that data passing through userspace. It therefore isn't surprising that these syscalls share an underlying entanglement of code (which is where the bulk of the space saving is to be had). What a tiny product developer should be asking himself, is: "Do I really need to efficiently move data between file descriptors?". If the answer no, he can disable CONFIG_SYSCALL_SPLICE to squeeze an extra 8KB out of his kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Tue, 25 Nov 2014 13:16:44 -0600 > >> David Miller writes: >> >>> From: j...@joshtriplett.org >>> Date: Tue, 25 Nov 2014 10:53:10 -0800 >>> It's not a "slippery slope"; it's been our standard practice for ages. >>> >>> We've never put an entire class of generic system calls behind >>> a config option. >> >> CONFIG_SYSVIPC has been in the kernel as long as I can remember. >> >> I seem to remember a plan to remove that code once userspace had >> finished migrating to more unixy interfaces to ipc. But in 20 years >> that migration does does not seem to have finished, or even look >> like it ever will. >> >> But if we started a slippery slope it was long long ago. > > Fair enough. > > Would be amusing if these tiny systems have it enabled. It would. In practice when I was playing in that space I had a hard time justifying CONFIG_NET and CONFIG_INET. Despite writing a network bootloader to use with kexec. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: ebied...@xmission.com (Eric W. Biederman) Date: Tue, 25 Nov 2014 13:16:44 -0600 > David Miller writes: > >> From: j...@joshtriplett.org >> Date: Tue, 25 Nov 2014 10:53:10 -0800 >> >>> It's not a "slippery slope"; it's been our standard practice for ages. >> >> We've never put an entire class of generic system calls behind >> a config option. > > CONFIG_SYSVIPC has been in the kernel as long as I can remember. > > I seem to remember a plan to remove that code once userspace had > finished migrating to more unixy interfaces to ipc. But in 20 years > that migration does does not seem to have finished, or even look > like it ever will. > > But if we started a slippery slope it was long long ago. Fair enough. Would be amusing if these tiny systems have it enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
David Miller writes: > From: j...@joshtriplett.org > Date: Tue, 25 Nov 2014 10:53:10 -0800 > >> It's not a "slippery slope"; it's been our standard practice for ages. > > We've never put an entire class of generic system calls behind > a config option. CONFIG_SYSVIPC has been in the kernel as long as I can remember. I seem to remember a plan to remove that code once userspace had finished migrating to more unixy interfaces to ipc. But in 20 years that migration does does not seem to have finished, or even look like it ever will. But if we started a slippery slope it was long long ago. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Theodore Ts'o Date: Tue, 25 Nov 2014 13:58:06 -0500 > On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote: >> >> And then if some fundamental part of userland (glibc, klibc, etc.) finds >> a useful way to use splice for a fundamental operation, we're back to >> square one. > > I'll note that the applications for these super-tiny kernels are > places where it's not likely they would be using glibc at all; think > very tiny embedded systems. The userspace tends to be highly > restricted for the same space reasons why there is an effort to make > the kernel as small as possible. This is why I mentioned klibc, in order to avoid replies like your's, it seems I have failed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 > It's not a "slippery slope"; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote: > > And then if some fundamental part of userland (glibc, klibc, etc.) finds > a useful way to use splice for a fundamental operation, we're back to > square one. I'll note that the applications for these super-tiny kernels are places where it's not likely they would be using glibc at all; think very tiny embedded systems. The userspace tends to be highly restricted for the same space reasons why there is an effort to make the kernel as small as possible. In these places, they are using Linux already, but they're using a 2.2 or 2.4 kernel because 3.0 is just too damned big. So the goal is to try to provide them an alternative which allows them to use a modern, but stripped down kernel. If glibc or klibc isn't going to work without splice, then it's not going to work on a pre 2.6 kernel anyway, so things are no worse with these systems anyway. After all, if we can get these systems to using a 3.x kernel w/o splice, that's surely better than their using a 2.2 or 2.4 kernel w/o the splice system, isn't it? Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
> From: Randy Dunlap
> Date: Tue, 25 Nov 2014 08:17:58 -0800
>
> > 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?
> >
> > 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?
>
> I think starting to compile out system calls is a very slippery
> slope we should not begin the journey down.
>
> This changes the forward facing interface to userspace.
It's not a "slippery slope"; it's been our standard practice for ages.
We started down that road long, long ago, when we first introduced
Kconfig and optional/modular features. /dev/* are user-facing
interfaces, yet you can compile them out or make them modular. /sys/*
and/proc/* are user-facing interfaces, yet you can compile part or all
of them out. Filesystem names passed to mount are user-facing
interfaces, yet you can compile them out. (Not just things like ext4;
think FUSE or overlayfs, which some applications will build upon and
require.) Some prctls are optional, new syscalls like BPF or inotify or
process_vm_{read,write}v are optional, hardware interfaces are optional,
control groups are optional, containers and namespaces are optional,
checkpoint/restart is optional, KVM is optional, kprobes are optional,
kmsg is optional, /dev/port is optional, ACL support is optional, USB
support (as used by libusb) is optional, sound interfaces are optional,
GPU interfaces are optional, even futexes are optional.
For every single one of those, userspace programs or libraries may
depend on that functionality, and summarily exit if it doesn't exist,
perhaps with a warning that you need to enable options in your kernel,
or perhaps with a simple "Function not implemented" or "No such file or
directory".
Out of the entire list above and the many more where that came from,
what makes syscalls unique? What's wildly different between
open("/dev/foo", ...) returning an error and sys_foo returning an error?
What makes syscalls so special out of the entire list above? We're not
breaking the ability to run old userspace on a new kernel, which *must*
be supported, and that includes not just syscalls but all user-facing
interfaces; we don't break userspace. But we've *never* guaranteed that
you can run old userspace on a new *allnoconfig* kernel.
All of these features will remain behind CONFIG_EXPERT, and all of them
warn that you can only use them if your userspace can cope.
I've actually been thinking of introducing a new CONFIG_ALL_SYSCALLS,
under which all the "enable support for foo syscall" can live, rather
than just piling all of them directly under CONFIG_EXPERT; that option
would then repeat in very clear terms the warning that if you disable
that option and then disable specific syscalls, you need to know exactly
what your target userspace uses. That would group together this whole
family of options, and make it clearer what the implications are.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: "Paul E. McKenney" Date: Tue, 25 Nov 2014 10:10:32 -0800 > I certainly sympathize with this concern, given the importance of software > portability. However, the tiny-hardware alternative appears ot some sort > of special-purpose embedded OS, which most definitely will suffer from > software compatibility issues. I guess that the good news is that much > of the tiny hardware that used to be 8 or 16 bits is now 32 bits, which > means that it has at least some chance of running some form of Linux. ;-) And then if some fundamental part of userland (glibc, klibc, etc.) finds a useful way to use splice for a fundamental operation, we're back to square one. I simply do not agree with modifying the user facing interface, especially one with decades of precedence. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote: > From: Randy Dunlap > Date: Tue, 25 Nov 2014 08:17:58 -0800 > > > 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? > > > > 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? > > I think starting to compile out system calls is a very slippery > slope we should not begin the journey down. > > This changes the forward facing interface to userspace. I certainly sympathize with this concern, given the importance of software portability. However, the tiny-hardware alternative appears ot some sort of special-purpose embedded OS, which most definitely will suffer from software compatibility issues. I guess that the good news is that much of the tiny hardware that used to be 8 or 16 bits is now 32 bits, which means that it has at least some chance of running some form of Linux. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Randy Dunlap Date: Tue, 25 Nov 2014 08:17:58 -0800 > 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? > > 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? I think starting to compile out system calls is a very slippery slope we should not begin the journey down. This changes the forward facing interface to userspace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Randy Dunlap rdun...@infradead.org Date: Tue, 25 Nov 2014 08:17:58 -0800 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? 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? I think starting to compile out system calls is a very slippery slope we should not begin the journey down. This changes the forward facing interface to userspace. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote: From: Randy Dunlap rdun...@infradead.org Date: Tue, 25 Nov 2014 08:17:58 -0800 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? 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? I think starting to compile out system calls is a very slippery slope we should not begin the journey down. This changes the forward facing interface to userspace. I certainly sympathize with this concern, given the importance of software portability. However, the tiny-hardware alternative appears ot some sort of special-purpose embedded OS, which most definitely will suffer from software compatibility issues. I guess that the good news is that much of the tiny hardware that used to be 8 or 16 bits is now 32 bits, which means that it has at least some chance of running some form of Linux. ;-) Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Tue, 25 Nov 2014 10:10:32 -0800 I certainly sympathize with this concern, given the importance of software portability. However, the tiny-hardware alternative appears ot some sort of special-purpose embedded OS, which most definitely will suffer from software compatibility issues. I guess that the good news is that much of the tiny hardware that used to be 8 or 16 bits is now 32 bits, which means that it has at least some chance of running some form of Linux. ;-) And then if some fundamental part of userland (glibc, klibc, etc.) finds a useful way to use splice for a fundamental operation, we're back to square one. I simply do not agree with modifying the user facing interface, especially one with decades of precedence. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
From: Randy Dunlap rdun...@infradead.org
Date: Tue, 25 Nov 2014 08:17:58 -0800
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?
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?
I think starting to compile out system calls is a very slippery
slope we should not begin the journey down.
This changes the forward facing interface to userspace.
It's not a slippery slope; it's been our standard practice for ages.
We started down that road long, long ago, when we first introduced
Kconfig and optional/modular features. /dev/* are user-facing
interfaces, yet you can compile them out or make them modular. /sys/*
and/proc/* are user-facing interfaces, yet you can compile part or all
of them out. Filesystem names passed to mount are user-facing
interfaces, yet you can compile them out. (Not just things like ext4;
think FUSE or overlayfs, which some applications will build upon and
require.) Some prctls are optional, new syscalls like BPF or inotify or
process_vm_{read,write}v are optional, hardware interfaces are optional,
control groups are optional, containers and namespaces are optional,
checkpoint/restart is optional, KVM is optional, kprobes are optional,
kmsg is optional, /dev/port is optional, ACL support is optional, USB
support (as used by libusb) is optional, sound interfaces are optional,
GPU interfaces are optional, even futexes are optional.
For every single one of those, userspace programs or libraries may
depend on that functionality, and summarily exit if it doesn't exist,
perhaps with a warning that you need to enable options in your kernel,
or perhaps with a simple Function not implemented or No such file or
directory.
Out of the entire list above and the many more where that came from,
what makes syscalls unique? What's wildly different between
open(/dev/foo, ...) returning an error and sys_foo returning an error?
What makes syscalls so special out of the entire list above? We're not
breaking the ability to run old userspace on a new kernel, which *must*
be supported, and that includes not just syscalls but all user-facing
interfaces; we don't break userspace. But we've *never* guaranteed that
you can run old userspace on a new *allnoconfig* kernel.
All of these features will remain behind CONFIG_EXPERT, and all of them
warn that you can only use them if your userspace can cope.
I've actually been thinking of introducing a new CONFIG_ALL_SYSCALLS,
under which all the enable support for foo syscall can live, rather
than just piling all of them directly under CONFIG_EXPERT; that option
would then repeat in very clear terms the warning that if you disable
that option and then disable specific syscalls, you need to know exactly
what your target userspace uses. That would group together this whole
family of options, and make it clearer what the implications are.
- Josh Triplett
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote: And then if some fundamental part of userland (glibc, klibc, etc.) finds a useful way to use splice for a fundamental operation, we're back to square one. I'll note that the applications for these super-tiny kernels are places where it's not likely they would be using glibc at all; think very tiny embedded systems. The userspace tends to be highly restricted for the same space reasons why there is an effort to make the kernel as small as possible. In these places, they are using Linux already, but they're using a 2.2 or 2.4 kernel because 3.0 is just too damned big. So the goal is to try to provide them an alternative which allows them to use a modern, but stripped down kernel. If glibc or klibc isn't going to work without splice, then it's not going to work on a pre 2.6 kernel anyway, so things are no worse with these systems anyway. After all, if we can get these systems to using a 3.x kernel w/o splice, that's surely better than their using a 2.2 or 2.4 kernel w/o the splice system, isn't it? Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Theodore Ts'o ty...@mit.edu Date: Tue, 25 Nov 2014 13:58:06 -0500 On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote: And then if some fundamental part of userland (glibc, klibc, etc.) finds a useful way to use splice for a fundamental operation, we're back to square one. I'll note that the applications for these super-tiny kernels are places where it's not likely they would be using glibc at all; think very tiny embedded systems. The userspace tends to be highly restricted for the same space reasons why there is an effort to make the kernel as small as possible. This is why I mentioned klibc, in order to avoid replies like your's, it seems I have failed. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
David Miller da...@davemloft.net writes: From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. CONFIG_SYSVIPC has been in the kernel as long as I can remember. I seem to remember a plan to remove that code once userspace had finished migrating to more unixy interfaces to ipc. But in 20 years that migration does does not seem to have finished, or even look like it ever will. But if we started a slippery slope it was long long ago. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: ebied...@xmission.com (Eric W. Biederman) Date: Tue, 25 Nov 2014 13:16:44 -0600 David Miller da...@davemloft.net writes: From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. CONFIG_SYSVIPC has been in the kernel as long as I can remember. I seem to remember a plan to remove that code once userspace had finished migrating to more unixy interfaces to ipc. But in 20 years that migration does does not seem to have finished, or even look like it ever will. But if we started a slippery slope it was long long ago. Fair enough. Would be amusing if these tiny systems have it enabled. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
David Miller da...@davemloft.net writes: From: ebied...@xmission.com (Eric W. Biederman) Date: Tue, 25 Nov 2014 13:16:44 -0600 David Miller da...@davemloft.net writes: From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. CONFIG_SYSVIPC has been in the kernel as long as I can remember. I seem to remember a plan to remove that code once userspace had finished migrating to more unixy interfaces to ipc. But in 20 years that migration does does not seem to have finished, or even look like it ever will. But if we started a slippery slope it was long long ago. Fair enough. Would be amusing if these tiny systems have it enabled. It would. In practice when I was playing in that space I had a hard time justifying CONFIG_NET and CONFIG_INET. Despite writing a network bootloader to use with kexec. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 02:04:41PM -0500, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 25 Nov 2014 10:53:10 -0800 It's not a slippery slope; it's been our standard practice for ages. We've never put an entire class of generic system calls behind a config option. I would have loved to make them optional individually, but they all are semantic variations of the same thing: Moving data between fd's without that data passing through userspace. It therefore isn't surprising that these syscalls share an underlying entanglement of code (which is where the bulk of the space saving is to be had). What a tiny product developer should be asking himself, is: Do I really need to efficiently move data between file descriptors?. If the answer no, he can disable CONFIG_SYSCALL_SPLICE to squeeze an extra 8KB out of his kernel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
[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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:00:59AM +0100, 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. > > HISTORY: > PATCH v4: > - Drops __splice_p() > - Let nfsd fall back to non-splice support when splice is compiled out > - Style fixes [...] > 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) I replied to one patch with a minor nit in the commit message. Other than that, I don't see any obvious issues with this. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
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. HISTORY: PATCH v4: - Drops __splice_p() - Let nfsd fall back to non-splice support when splice is compiled out - Style fixes PATCH v3: - Fixup commit logs so that they are consistent with patch strategy - Style fixes PATCH v2: - Avoid the ifdef mess introduced in PATCH v1 by mocking out exported splice functions. STRATEGY: a. With the goal of eventually compiling out fs/splice.c, several functions that are only used in support of the the splice family of syscalls are moved into fs/splice.c from fs/read_write.c. The kernel_write function that is not used to support the splice syscalls is moved to fs/read_write.c. b. Introduce an EXPERT kernel configuration option; CONFIG_SYSCALL_SPLICE; to compile out the splice family of syscalls. This removes all userspace uses of the splice infrastructure. c. Splice exports an operations struct, nosteal_pipe_buf_ops. Eliminate the use of this struct when CONFIG_SYSCALL_SPLICE is undefined, so that splice can later be compiled out. d. Let nfsd fall back to non-splice support when splice is compiled out. e. Compile out fs/splice.c. Functions exported by fs/splice are mocked out with failing static inlines. This is done so as to all but eliminate the maintenance burden on file-system drivers. 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) function old new delta sys_pwritev 115 122 +7 sys_preadv 115 122 +7 fdput_pos 29 36 +7 sys_pwrite64 115 116 +1 sys_pread64 115 116 +1 pipe_to_null 4 - -4 generic_pipe_buf_nosteal 6 - -6 spd_release_page 10 - -10 fdput 11 - -11 PageUptodate 22 11 -11 lock_page 36 24 -12 signal_pending39 26 -13 fdget 56 42 -14 page_cache_pipe_buf_release 16 - -16 user_page_pipe_buf_ops20 - -20 splice_write_null 24 4 -20 page_cache_pipe_buf_ops 20 - -20 nosteal_pipe_buf_ops 20 - -20 default_pipe_buf_ops 20 - -20 generic_splice_sendpage 24 - -24 user_page_pipe_buf_steal 25 - -25 splice_shrink_spd 27 - -27 pipe_to_user 43 - -43 direct_splice_actor 47 - -47 default_file_splice_write 49 - -49 wakeup_pipe_writers 54 - -54 wakeup_pipe_readers 54 - -54 write_pipe_buf71 - -71 page_cache_pipe_buf_confirm 80 - -80 splice_grow_spd 87 - -87 do_splice_to 87 - -87 ipipe_prep.part 92 - -92 splice_from_pipe 93 - -93 splice_from_pipe_next107 --107 pipe_to_sendpage 109 --109 page_cache_pipe_buf_steal114 --114 opipe_prep.part 119 --119 sys_sendfile 122 --122 generic_file_splice_read 131 8-123 sys_sendfile64 126 --126 sys_vmsplice 137 --137 do_splice_direct 148 --148 vmsplice_to_user 205 --205 __splice_from_pipe 246 --246 splice_direct_to_actor 348 --348 splice_to_pipe 371 --371 do_sendfile
[PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
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. HISTORY: PATCH v4: - Drops __splice_p() - Let nfsd fall back to non-splice support when splice is compiled out - Style fixes PATCH v3: - Fixup commit logs so that they are consistent with patch strategy - Style fixes PATCH v2: - Avoid the ifdef mess introduced in PATCH v1 by mocking out exported splice functions. STRATEGY: a. With the goal of eventually compiling out fs/splice.c, several functions that are only used in support of the the splice family of syscalls are moved into fs/splice.c from fs/read_write.c. The kernel_write function that is not used to support the splice syscalls is moved to fs/read_write.c. b. Introduce an EXPERT kernel configuration option; CONFIG_SYSCALL_SPLICE; to compile out the splice family of syscalls. This removes all userspace uses of the splice infrastructure. c. Splice exports an operations struct, nosteal_pipe_buf_ops. Eliminate the use of this struct when CONFIG_SYSCALL_SPLICE is undefined, so that splice can later be compiled out. d. Let nfsd fall back to non-splice support when splice is compiled out. e. Compile out fs/splice.c. Functions exported by fs/splice are mocked out with failing static inlines. This is done so as to all but eliminate the maintenance burden on file-system drivers. 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) function old new delta sys_pwritev 115 122 +7 sys_preadv 115 122 +7 fdput_pos 29 36 +7 sys_pwrite64 115 116 +1 sys_pread64 115 116 +1 pipe_to_null 4 - -4 generic_pipe_buf_nosteal 6 - -6 spd_release_page 10 - -10 fdput 11 - -11 PageUptodate 22 11 -11 lock_page 36 24 -12 signal_pending39 26 -13 fdget 56 42 -14 page_cache_pipe_buf_release 16 - -16 user_page_pipe_buf_ops20 - -20 splice_write_null 24 4 -20 page_cache_pipe_buf_ops 20 - -20 nosteal_pipe_buf_ops 20 - -20 default_pipe_buf_ops 20 - -20 generic_splice_sendpage 24 - -24 user_page_pipe_buf_steal 25 - -25 splice_shrink_spd 27 - -27 pipe_to_user 43 - -43 direct_splice_actor 47 - -47 default_file_splice_write 49 - -49 wakeup_pipe_writers 54 - -54 wakeup_pipe_readers 54 - -54 write_pipe_buf71 - -71 page_cache_pipe_buf_confirm 80 - -80 splice_grow_spd 87 - -87 do_splice_to 87 - -87 ipipe_prep.part 92 - -92 splice_from_pipe 93 - -93 splice_from_pipe_next107 --107 pipe_to_sendpage 109 --109 page_cache_pipe_buf_steal114 --114 opipe_prep.part 119 --119 sys_sendfile 122 --122 generic_file_splice_read 131 8-123 sys_sendfile64 126 --126 sys_vmsplice 137 --137 do_splice_direct 148 --148 vmsplice_to_user 205 --205 __splice_from_pipe 246 --246 splice_direct_to_actor 348 --348 splice_to_pipe 371 --371 do_sendfile
Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
On Tue, Nov 25, 2014 at 12:00:59AM +0100, 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. HISTORY: PATCH v4: - Drops __splice_p() - Let nfsd fall back to non-splice support when splice is compiled out - Style fixes [...] 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) I replied to one patch with a minor nit in the commit message. Other than that, I don't see any obvious issues with this. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
