Woe be unto he who builds their filesystems as modules.
Signed-off-by: Jeff Garzik <[email protected]>
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)
{
On Thu, Mar 30 2006, Jeff Garzik wrote:
>
> Woe be unto he who builds their filesystems as modules.
>
> Signed-off-by: Jeff Garzik <[email protected]>
>
> 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
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?
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
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
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
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
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
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
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