lkml.org 
[lkml]   [2014]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [fuse-devel] [PATCH 4/6] fs/fuse: support compiling out splice
On Mon, Nov 24, 2014 at 12:22:14PM -0800, Greg KH wrote:
> On Mon, Nov 24, 2014 at 12:14:50PM -0800, josh@joshtriplett.org wrote:
> > > 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.


\
 
 \ /
  Last update: 2014-11-24 23:21    [W:1.837 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site