[PATCH] splice exports

[PATCH] splice exports

[Jeff Garzik]

Woe be unto he who builds their filesystems as modules.

Signed-off-by: Jeff Garzik <jeff@garzik.org>

diff --git a/fs/splice.c b/fs/splice.c
index 4a026f9..7c2bbf1 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -22,6 +22,7 @@
 #include <linux/pipe_fs_i.h>
 #include <linux/mm_inline.h>
 #include <linux/swap.h>
+#include <linux/module.h>
 
 /*
  * Passed to the actors
@@ -567,6 +568,9 @@ ssize_t generic_splice_sendpage(struct i
 	return move_from_pipe(inode, out, len, flags, pipe_to_sendpage);
 }
 
+EXPORT_SYMBOL(generic_file_splice_write);
+EXPORT_SYMBOL(generic_file_splice_read);
+
 static long do_splice_from(struct inode *pipe, struct file *out, size_t len,
 			   unsigned int flags)
 {

Re: [PATCH] splice exports

[Jens Axboe]

On Thu, Mar 30 2006, Jeff Garzik wrote:
> 
> Woe be unto he who builds their filesystems as modules.
> 
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
> 
> diff --git a/fs/splice.c b/fs/splice.c
> index 4a026f9..7c2bbf1 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -22,6 +22,7 @@
>  #include <linux/pipe_fs_i.h>
>  #include <linux/mm_inline.h>
>  #include <linux/swap.h>
> +#include <linux/module.h>
>  
>  /*
>   * Passed to the actors
> @@ -567,6 +568,9 @@ ssize_t generic_splice_sendpage(struct i
>  	return move_from_pipe(inode, out, len, flags, pipe_to_sendpage);
>  }
>  
> +EXPORT_SYMBOL(generic_file_splice_write);
> +EXPORT_SYMBOL(generic_file_splice_read);
> +
>  static long do_splice_from(struct inode *pipe, struct file *out, size_t len,
>  			   unsigned int flags)
>  {

Thanks Jeff!

-- 
Jens Axboe

Re: [PATCH] splice exports

[Arjan van de Ven]

On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> Woe be unto he who builds their filesystems as modules.


since splice support is highly linux specific and new.. shouldn't these
be _GPL exports?

Re: [PATCH] splice exports

[Jens Axboe]

On Fri, Mar 31 2006, Arjan van de Ven wrote:
> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> > Woe be unto he who builds their filesystems as modules.
> 
> 
> since splice support is highly linux specific and new.. shouldn't these
> be _GPL exports?

Yes they should, I'll add that to the current splice tree.

-- 
Jens Axboe

Re: [PATCH] splice exports

[Sam Ravnborg]

On Thu, Mar 30, 2006 at 11:06:13PM -0500, Jeff Garzik wrote:
  /*
>   * Passed to the actors
> @@ -567,6 +568,9 @@ ssize_t generic_splice_sendpage(struct i
>  	return move_from_pipe(inode, out, len, flags, pipe_to_sendpage);
>  }
>  
> +EXPORT_SYMBOL(generic_file_splice_write);
> +EXPORT_SYMBOL(generic_file_splice_read);
Can we please have them right after the closing brace of the function
defining these function instead.

	Sam

Re: [PATCH] splice exports

[Jens Axboe]

On Fri, Mar 31 2006, Sam Ravnborg wrote:
> On Thu, Mar 30, 2006 at 11:06:13PM -0500, Jeff Garzik wrote:
>   /*
> >   * Passed to the actors
> > @@ -567,6 +568,9 @@ ssize_t generic_splice_sendpage(struct i
> >  	return move_from_pipe(inode, out, len, flags, pipe_to_sendpage);
> >  }
> >  
> > +EXPORT_SYMBOL(generic_file_splice_write);
> > +EXPORT_SYMBOL(generic_file_splice_read);
> Can we please have them right after the closing brace of the function
> defining these function instead.

http://brick.kernel.dk/git/?p=linux-2.6-block.git;a=commitdiff;h=ef9f6c8461ec21ab5ce02890e1d522e300e2703e

-- 
Jens Axboe

Re: [PATCH] splice exports

[Jeff Garzik]

Jens Axboe wrote:
> On Fri, Mar 31 2006, Arjan van de Ven wrote:
>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
>>> Woe be unto he who builds their filesystems as modules.
>>
>> since splice support is highly linux specific and new.. shouldn't these
>> be _GPL exports?
> 
> Yes they should, I'll add that to the current splice tree.

Why?  We don't usually restrict filesystems in such ways...  I would 
rather a binary-only module reference generic_file_splice_read() than 
create its own.

	Jeff

Re: [PATCH] splice exports

[Jens Axboe]

On Fri, Mar 31 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Fri, Mar 31 2006, Arjan van de Ven wrote:
> >>On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> >>>Woe be unto he who builds their filesystems as modules.
> >>
> >>since splice support is highly linux specific and new.. shouldn't these
> >>be _GPL exports?
> >
> >Yes they should, I'll add that to the current splice tree.
> 
> Why?  We don't usually restrict filesystems in such ways...  I would 
> rather a binary-only module reference generic_file_splice_read() than 
> create its own.

You could use that very same argument for any piece of the kernel, then,
so I don't think that adds much value to _not_ exporting it GPL.

-- 
Jens Axboe

Re: [PATCH] splice exports

[Jeff Garzik]

Jens Axboe wrote:
> On Fri, Mar 31 2006, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
>>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
>>>>> Woe be unto he who builds their filesystems as modules.
>>>> since splice support is highly linux specific and new.. shouldn't these
>>>> be _GPL exports?
>>> Yes they should, I'll add that to the current splice tree.
>> Why?  We don't usually restrict filesystems in such ways...  I would 
>> rather a binary-only module reference generic_file_splice_read() than 
>> create its own.
> 
> You could use that very same argument for any piece of the kernel, then,
> so I don't think that adds much value to _not_ exporting it GPL.

Not really, because I'm considering the Real World(tm) users, not 
abstract theory :)  The other filesystem junk is exported non-GPL, and 
existing binary-only filesystems use that stuff.

IOW its a bit rude to say "oh you can have your BO filesystem, just not 
splice support."

	Jeff

Re: [PATCH] splice exports

[Arjan van de Ven]

On Fri, 2006-03-31 at 18:14 -0500, Jeff Garzik wrote:
> Jens Axboe wrote:
> > On Fri, Mar 31 2006, Jeff Garzik wrote:
> >> Jens Axboe wrote:
> >>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
> >>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> >>>>> Woe be unto he who builds their filesystems as modules.
> >>>> since splice support is highly linux specific and new.. shouldn't these
> >>>> be _GPL exports?
> >>> Yes they should, I'll add that to the current splice tree.
> >> Why?  We don't usually restrict filesystems in such ways...  I would 
> >> rather a binary-only module reference generic_file_splice_read() than 
> >> create its own.
> > 
> > You could use that very same argument for any piece of the kernel, then,
> > so I don't think that adds much value to _not_ exporting it GPL.
> 
> Not really, because I'm considering the Real World(tm) users, not 
> abstract theory :)  The other filesystem junk is exported non-GPL, and 
> existing binary-only filesystems use that stuff.
> 
> IOW its a bit rude to say "oh you can have your BO filesystem, just not 
> splice support."


it's a bit like saying "you can use all the standard unix interfaces,
but these are very linux specific"; eg the same arguments for making lsm
and other pieces _GPL; they're so linux specific that users that use
these do so with linux in mind etc

Re: [PATCH] splice exports

[Jens Axboe]

On Sat, Apr 01 2006, Arjan van de Ven wrote:
> On Fri, 2006-03-31 at 18:14 -0500, Jeff Garzik wrote:
> > Jens Axboe wrote:
> > > On Fri, Mar 31 2006, Jeff Garzik wrote:
> > >> Jens Axboe wrote:
> > >>> On Fri, Mar 31 2006, Arjan van de Ven wrote:
> > >>>> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> > >>>>> Woe be unto he who builds their filesystems as modules.
> > >>>> since splice support is highly linux specific and new.. shouldn't these
> > >>>> be _GPL exports?
> > >>> Yes they should, I'll add that to the current splice tree.
> > >> Why?  We don't usually restrict filesystems in such ways...  I would 
> > >> rather a binary-only module reference generic_file_splice_read() than 
> > >> create its own.
> > > 
> > > You could use that very same argument for any piece of the kernel, then,
> > > so I don't think that adds much value to _not_ exporting it GPL.
> > 
> > Not really, because I'm considering the Real World(tm) users, not 
> > abstract theory :)  The other filesystem junk is exported non-GPL, and 
> > existing binary-only filesystems use that stuff.
> > 
> > IOW its a bit rude to say "oh you can have your BO filesystem, just not 
> > splice support."
> 
> 
> it's a bit like saying "you can use all the standard unix interfaces,
> but these are very linux specific"; eg the same arguments for making lsm
> and other pieces _GPL; they're so linux specific that users that use
> these do so with linux in mind etc

Linus seems to agree with the _GPL not being appropriate as well, so I
guess I'll bow to the majority. This time :-)

-- 
Jens Axboe