* Greg KH (greg@xxxxxxxxx) wrote: > On Thu, Dec 01, 2011 at 03:18:03PM -0500, Mathieu Desnoyers wrote: > > * Greg KH (greg@xxxxxxxxx) wrote: > > > On Wed, Nov 30, 2011 at 01:34:20PM -0500, Mathieu Desnoyers wrote: > > > > LTTng needs this symbol exported because it implements its own splice > > > > actor. > > > > > > > > Exporting to all modules following the general policy of splice.c (this > > > > is what other EXPORTs do in this file). > > > > > > > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> > > > > --- > > > > fs/splice.c | 1 + > > > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/fs/splice.c b/fs/splice.c > > > > index fa2defa..492585d 100644 > > > > --- a/fs/splice.c > > > > +++ b/fs/splice.c > > > > @@ -263,6 +263,7 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe, > > > > > > > > return ret; > > > > } > > > > +EXPORT_SYMBOL(splice_to_pipe); > > > > > > Why not EXPORT_SYMBOL_GPL()? > > > > Because all other exported symbols in splice.c are "EXPORT_SYMBOL", as I > > wrote in the changelog above. > > > > compudj@thinkos:~/git/linux/fs$ grep EXPORT_SYMBOL_GPL splice.c > > compudj@thinkos:~/git/linux/fs$ grep EXPORT_SYMBOL splice.c > > EXPORT_SYMBOL(generic_file_splice_read); > > EXPORT_SYMBOL(default_file_splice_read); > > EXPORT_SYMBOL(pipe_to_file); > > EXPORT_SYMBOL(splice_from_pipe_feed); > > EXPORT_SYMBOL(splice_from_pipe_next); > > EXPORT_SYMBOL(splice_from_pipe_begin); > > EXPORT_SYMBOL(splice_from_pipe_end); > > EXPORT_SYMBOL(__splice_from_pipe); > > EXPORT_SYMBOL(generic_file_splice_write); > > EXPORT_SYMBOL(generic_splice_sendpage); > > EXPORT_SYMBOL(splice_direct_to_actor); > > > > So is it better to follow the other exports or use a GPL export here ? > > Using GPL is up to the author, but to be "nice" in that you weren't the > original author, you can always propose it and have them decide to > change it. It shows a "good faith" that you are wanting this exported > only for in-kernel module code. I've made sure they were all "GPL". Then it will be up to the maintainers to decide if they want to open them up further. Thanks, Mathieu > > thanks, > > greg k-h -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
