Thread (1 message) 1 message, 1 author, 2014-11-24

Re: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice

From: Pieter Smith <hidden>
Date: 2014-11-24 21:49:26
Also in: linux-fsdevel, lkml, netdev

On Mon, Nov 24, 2014 at 12:22:14PM -0800, Greg KH wrote:
On Mon, Nov 24, 2014 at 12:14:50PM -0800, josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org wrote:
quoted
quoted
I would, again, argue that stuff like __splice_p() not be implemented at
all please.  It will only cause a huge proliferation of stuff like this
that will not make any sense, and only cause a trivial, if any, amount
of code savings.

I thought you were going to not do this type of thing until you got the
gcc optimizer working for function callbacks.
Compared to the previous patchset, there are now only two instances of
ifdefs outside of the splice code for this, and this is one of them.  In
this case, the issue is no longer about making the code for this
splice_read function disappear, but rather to eliminate a reference to a
bit of splice functionality (used *inside* the FUSE splice code) that
will not work without SPLICE_SYSCALL.

Would you prefer to see this specific case handled via an #ifdef in
fs/fuse/dev.c rather than introducing a __splice_p that people might be
inclined to propagate?  That'd be fine; the code could simply wrap
fuse_dev_splice_read in an #ifdef and have the #else define a NULL
fuse_dev_splice_read.
Yes, I would prefer that, but I'm not the fuse maintainer.

thanks,

greg k-h
Okay. I'll do my part to prevent the type of proliferation guaranteed to rate
high on the respected K-H icky-scale. __splice_p() goes the way of the dodo
in favor of the solution presented by Josh.

I pray that the Gods of fuse maintenance will look favorable upon the result.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help