On Mon, Nov 24, 2014 at 12:22:14PM -0800, Greg KH wrote: > On Mon, Nov 24, 2014 at 12:14:50PM -0800, josh@xxxxxxxxxxxxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
