From: Randy Dunlap <redacted>
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-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
From: Randy Dunlap <redacted>
Date: Tue, 25 Nov 2014 08:17:58 -0800
quoted
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
From: "Paul E. McKenney" <redacted>
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.
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
From: Randy Dunlap <redacted>
Date: Tue, 25 Nov 2014 08:17:58 -0800
quoted
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
On Tue, 25 Nov 2014 14:04:41 -0500 (EST)
David Miller [off-list ref] wrote:
From: josh@joshtriplett.org
Date: Tue, 25 Nov 2014 10:53:10 -0800
quoted
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