From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: rdunlap@infradead.org, pieter@boesman.nl, josh@joshtriplett.org,
alexander.h.duyck@intel.com, viro@zeniv.linux.org.uk,
ast@plumgrid.com, akpm@linux-foundation.org, beber@meleeweb.net,
catalina.mocanu@gmail.com, dborkman@redhat.com,
edumazet@google.com, ebiederm@xmission.com, fabf@skynet.be,
fuse-devel@lists.sourceforge.net, geert@linux-m68k.org,
hughd@google.com, iulia.manda21@gmail.com, JBeulich@suse.com,
bfields@fieldses.org, jlayton@poochiereds.net,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
mcgrof@suse.com, mattst88@gmail.com, mgorman@suse.de,
mst@redhat.com, miklos@szeredi.hu, netdev@vger.kernel.org,
oleg@redhat.com, Paul.Durrant@citrix.com, pefoley2@pefoley.com,
tgraf@suug.ch, therbert@google.com,
trond.myklebust@primarydata.com, willemb@google.com,
xiaoguangrong@linux.vnet.ibm.com, zhenglong
Subject: Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
Date: Tue, 25 Nov 2014 10:10:32 -0800 [thread overview]
Message-ID: <20141125181032.GJ5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <20141125.121305.2094097848188324942.davem@davemloft.net>
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
> From: Randy Dunlap <rdunlap@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
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: rdunlap@infradead.org, pieter@boesman.nl, josh@joshtriplett.org,
alexander.h.duyck@intel.com, viro@zeniv.linux.org.uk,
ast@plumgrid.com, akpm@linux-foundation.org, beber@meleeweb.net,
catalina.mocanu@gmail.com, dborkman@redhat.com,
edumazet@google.com, ebiederm@xmission.com, fabf@skynet.be,
fuse-devel@lists.sourceforge.net, geert@linux-m68k.org,
hughd@google.com, iulia.manda21@gmail.com, JBeulich@suse.com,
bfields@fieldses.org, jlayton@poochiereds.net,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
mcgrof@suse.com, mattst88@gmail.com, mgorman@suse.de,
mst@redhat.com, miklos@szeredi.hu, netdev@vger.kernel.org,
oleg@redhat.com, Paul.Durrant@citrix.com, pefoley2@pefoley.com,
tgraf@suug.ch, therbert@google.com,
trond.myklebust@primarydata.com, willemb@google.com,
xiaoguangrong@linux.vnet.ibm.com, zhenglong.cai@cs2c.com.cn
Subject: Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
Date: Tue, 25 Nov 2014 10:10:32 -0800 [thread overview]
Message-ID: <20141125181032.GJ5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <20141125.121305.2094097848188324942.davem@davemloft.net>
On Tue, Nov 25, 2014 at 12:13:05PM -0500, David Miller wrote:
> From: Randy Dunlap <rdunlap@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
next prev parent reply other threads:[~2014-11-25 18:10 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 23:00 [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile) Pieter Smith
2014-11-24 23:00 ` Pieter Smith
2014-11-24 23:00 ` Pieter Smith
2014-11-24 23:01 ` [PATCH v4 1/7] fs: move sendfile syscall into fs/splice Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` [PATCH v4 2/7] fs: moved kernel_write to fs/read_write Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` [PATCH v4 3/7] fs/splice: support compiling out splice-family syscalls Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-25 0:49 ` Josh Triplett
2014-11-25 0:49 ` Josh Triplett
2014-11-25 0:49 ` Josh Triplett
2014-11-24 23:01 ` [PATCH v4 4/7] fs/fuse: support compiling out splice Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` [PATCH v4 5/7] fs/nfsd: " Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
[not found] ` <1416870079-15254-1-git-send-email-pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
2014-11-24 23:01 ` [PATCH v4 6/7] net/core: " Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` [PATCH v4 7/7] fs/splice: full support for " Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-24 23:01 ` Pieter Smith
2014-11-25 0:52 ` [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile) Josh Triplett
2014-11-25 0:52 ` Josh Triplett
2014-11-25 0:52 ` Josh Triplett
[not found] ` <5474ABB6.3030400@infradead.org>
[not found] ` <5474ABB6.3030400-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-11-25 17:13 ` David Miller
2014-11-25 17:13 ` David Miller
2014-11-25 18:10 ` Paul E. McKenney [this message]
2014-11-25 18:10 ` Paul E. McKenney
2014-11-25 18:24 ` David Miller
2014-11-25 18:24 ` David Miller
[not found] ` <20141125.132445.152609149279137368.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-11-25 18:58 ` Theodore Ts'o
2014-11-25 18:58 ` Theodore Ts'o
[not found] ` <20141125185806.GA28116-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-11-25 19:05 ` David Miller
2014-11-25 19:05 ` David Miller
2014-11-25 18:53 ` josh
2014-11-25 18:53 ` josh
2014-11-25 19:04 ` David Miller
2014-11-25 19:04 ` David Miller
[not found] ` <20141125.140441.401150380839514113.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-11-25 19:16 ` Eric W. Biederman
2014-11-25 19:16 ` Eric W. Biederman
[not found] ` <87egsr9jkz.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2014-11-25 19:27 ` David Miller
2014-11-25 19:27 ` David Miller
[not found] ` <20141125.142741.1620673255148724338.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-11-25 20:01 ` Eric W. Biederman
2014-11-25 20:01 ` Eric W. Biederman
2014-11-25 20:11 ` Pieter Smith
2014-11-25 20:11 ` Pieter Smith
2014-11-25 20:11 ` Pieter Smith
2014-11-26 12:19 ` One Thousand Gnomes
2014-11-26 12:19 ` One Thousand Gnomes
2014-11-25 19:00 ` josh-iaAMLnmF4UmaiuxdJuQwMA
2014-11-25 22:08 ` josh-iaAMLnmF4UmaiuxdJuQwMA
2014-11-25 22:08 ` josh-iaAMLnmF4UmaiuxdJuQwMA
2014-11-25 22:08 ` josh
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=20141125181032.GJ5050@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=JBeulich@suse.com \
--cc=Paul.Durrant@citrix.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@intel.com \
--cc=ast@plumgrid.com \
--cc=beber@meleeweb.net \
--cc=bfields@fieldses.org \
--cc=catalina.mocanu@gmail.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=fabf@skynet.be \
--cc=fuse-devel@lists.sourceforge.net \
--cc=geert@linux-m68k.org \
--cc=hughd@google.com \
--cc=iulia.manda21@gmail.com \
--cc=jlayton@poochiereds.net \
--cc=josh@joshtriplett.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=mcgrof@suse.com \
--cc=mgorman@suse.de \
--cc=miklos@szeredi.hu \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pefoley2@pefoley.com \
--cc=pieter@boesman.nl \
--cc=rdunlap@infradead.org \
--cc=tgraf@suug.ch \
--cc=therbert@google.com \
--cc=trond.myklebust@primarydata.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willemb@google.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
/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.