On Fri, Dec 4, 2009 at 4:58 PM, Greg KH <greg@kroah.com> wrote:
> I have never rejected aufs to go into the staging tree, nor has anyone
> asked me about it.
>
> Yes, the code is horrible, and it does really nasty things, and most
> modern distros are using a FUSE based filesystem instead of it for their
> live cds, but that doesn't mean that I wouldn't take it into the staging
> tree
>
> As long as someone is willing to help maintain it, and work to either
> just keep it going, or actually get it merged into mainline someday,
> I'll be glad to take it.

Thanks Greg, seems like aufs is welcomed into staging.

Luis

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

CC'ing Junjiro on this. Not sure if he is on the kernel-team mailing
list these days.

We've worked with him before to try to get his code more upstream acceptable.

Regards,
Amit

On Sat, Dec 5, 2009 at 5:47 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Dec 4, 2009 at 4:58 PM, Greg KH <greg@kroah.com> wrote:
>> I have never rejected aufs to go into the staging tree, nor has anyone
>> asked me about it.
>>
>> Yes, the code is horrible, and it does really nasty things, and most
>> modern distros are using a FUSE based filesystem instead of it for their
>> live cds, but that doesn't mean that I wouldn't take it into the staging
>> tree
>>
>> As long as someone is willing to help maintain it, and work to either
>> just keep it going, or actually get it merged into mainline someday,
>> I'll be glad to take it.
>
> Thanks Greg, seems like aufs is welcomed into staging.
>
> *Luis
>
> --
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Amit Kucheria:
> CC'ing Junjiro on this. Not sure if he is on the kernel-team mailing
> list these days.

Thanx, Amit.
I left Ubuntu kernel-team mailing list when I knew aufs was dropped from
Ubuntu kernel.


> > On Fri, Dec 4, 2009 at 4:58 PM, Greg KH <greg@kroah.com> wrote:
> >> I have never rejected aufs to go into the staging tree, nor has anyone
> >> asked me about it.

Exactly.
I didn't ask you to do so because I was advised such like this (and I
reported it to Amit, Pete Graner and Colin Watson).
-------------------- begin quote --------------------
> Currently I am confused by many kernel trees.
> Will you advise me which tree I should try first, -mm, -next, -staging,
> or -2.6 (mainline)? And who should I sent to?

For a filesystem: work against Linus's latest tree.
-------------------- end quote --------------------

And I sent the aufs design to LKML in last February, and patches in
March. There was a small discussion on LKML. Greg, you might remember
that you had written about the entries under debugfs and sysfs.

As far as I know, in order to be merged into the staging tree, there are
some conditions particulary,
-------------------- begin quote --------------------
- Some symbols might need to be exported from the main portion of the kernel
source tree. This is acceptable as long as the relevant subsystem
maintainer agrees with this export.
-------------------- end quote --------------------

And Christoph Hellwig wrote strong NACK about aufs (in April).
-------------------- begin quote --------------------
Just making sure these exports aren't going to accidentally put in if
Greg happens to suck this pile into the staging tree.
-------------------- end quote --------------------
http://marc.info/?l=linux-kernel&m=123938262620587&w=2

Also he declared
"we want to do vfs-level union mounts, and at the storage summit we've
actually moved forward on that"

And resulting,
-------------------- begin quote --------------------
> I have been asked to include aufs into mainline from several people
> several times. As long as you have strong NACK for aufs and reject all
> union-type filesystems, I have to give up unwillingly and will answer
> them "Aufs was rejected. Let's give it up."

Yes, that's the case.
-------------------- end quote --------------------

> >> As long as someone is willing to help maintain it, and work to either
> >> just keep it going, or actually get it merged into mainline someday,
> >> I'll be glad to take it.

NACK from Christoph is the key, I am afraid.
But if the linux-staging tree accepts exporting VFS functions for aufs,
I will make the aufs GIT branch for staging.


J. R. Okajima

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Dec 07, 2009 at 01:27:25PM +0900, hooanon05@yahoo.co.jp wrote:
>
> Amit Kucheria:
> > CC'ing Junjiro on this. Not sure if he is on the kernel-team mailing
> > list these days.
>
> Thanx, Amit.
> I left Ubuntu kernel-team mailing list when I knew aufs was dropped from
> Ubuntu kernel.
>
>
> > > On Fri, Dec 4, 2009 at 4:58 PM, Greg KH <greg@kroah.com> wrote:
> > >> I have never rejected aufs to go into the staging tree, nor has anyone
> > >> asked me about it.
>
> Exactly.
> I didn't ask you to do so because I was advised such like this (and I
> reported it to Amit, Pete Graner and Colin Watson).
> -------------------- begin quote --------------------
> > Currently I am confused by many kernel trees.
> > Will you advise me which tree I should try first, -mm, -next, -staging,
> > or -2.6 (mainline)? And who should I sent to?
>
> For a filesystem: work against Linus's latest tree.
> -------------------- end quote --------------------
>
> And I sent the aufs design to LKML in last February, and patches in
> March. There was a small discussion on LKML. Greg, you might remember
> that you had written about the entries under debugfs and sysfs.
>
> As far as I know, in order to be merged into the staging tree, there are
> some conditions particulary,
> -------------------- begin quote --------------------
> - Some symbols might need to be exported from the main portion of the kernel
> source tree. This is acceptable as long as the relevant subsystem
> maintainer agrees with this export.
> -------------------- end quote --------------------
>
> And Christoph Hellwig wrote strong NACK about aufs (in April).
> -------------------- begin quote --------------------
> Just making sure these exports aren't going to accidentally put in if
> Greg happens to suck this pile into the staging tree.
> -------------------- end quote --------------------
> http://marc.info/?l=linux-kernel&m=123938262620587&w=2
>
> Also he declared
> "we want to do vfs-level union mounts, and at the storage summit we've
> actually moved forward on that"
>
> And resulting,
> -------------------- begin quote --------------------
> > I have been asked to include aufs into mainline from several people
> > several times. As long as you have strong NACK for aufs and reject all
> > union-type filesystems, I have to give up unwillingly and will answer
> > them "Aufs was rejected. Let's give it up."
>
> Yes, that's the case.
> -------------------- end quote --------------------
>
> > >> As long as someone is willing to help maintain it, and work to either
> > >> just keep it going, or actually get it merged into mainline someday,
> > >> I'll be glad to take it.
>
> NACK from Christoph is the key, I am afraid.
> But if the linux-staging tree accepts exporting VFS functions for aufs,
> I will make the aufs GIT branch for staging.

Ok, if aufs relies on exports that Christoph is not going to accept,
then there's nothing I can do to add the code to the kernel.

_unless_ the code will work if it is built in. What symbols are needed
by aufs, and is only to allow it to be built as a module, but not as a
built-in filesystem?

If built-in will work, then it could work in staging, right?

thanks,

greg k-h

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Greg KH:
> Ok, if aufs relies on exports that Christoph is not going to accept,
> then there's nothing I can do to add the code to the kernel.
>
> _unless_ the code will work if it is built in. What symbols are needed
> by aufs, and is only to allow it to be built as a module, but not as a
> built-in filesystem?
>
> If built-in will work, then it could work in staging, right?

The word 'export' I use here might be incorrect.
Strictly speaking, it is "make some functions global" instead of "export
symbols to external module."
Actually the aufs patches I sent to LKML were not to build aufs as a
module. It supports CONFIG_AUFS_FS=y only.
There exist another GIT tree to build aufs as a module.


diff --git a/fs/namei.c b/fs/namei.c
index d11f404..7d28f56 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1219,7 +1219,7 @@ out:
* needs parent already locked. Doesn't follow mounts.
* SMP-safe.
*/
-static struct dentry *lookup_hash(struct nameidata *nd)
+struct dentry *lookup_hash(struct nameidata *nd)
{
int err;

@@ -1229,7 +1229,7 @@ static struct dentry *lookup_hash(struct nameidata *nd)
return __lookup_hash(&nd->last, nd->path.dentry, nd);
}

-static int __lookup_one_len(const char *name, struct qstr *this,
+int __lookup_one_len(const char *name, struct qstr *this,
struct dentry *base, int len)
{
unsigned long hash;
diff --git a/fs/splice.c b/fs/splice.c
index 7394e9e..77184f0 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1051,8 +1051,8 @@ EXPORT_SYMBOL(generic_splice_sendpage);
/*
* Attempt to initiate a splice from pipe to file.
*/
-static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
- loff_t *ppos, size_t len, unsigned int flags)
+long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
+ loff_t *ppos, size_t len, unsigned int flags)
{
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *,
loff_t *, size_t, unsigned int);
@@ -1078,9 +1078,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
/*
* Attempt to initiate a splice from a file to a pipe.
*/
-static long do_splice_to(struct file *in, loff_t *ppos,
- struct pipe_inode_info *pipe, size_t len,
- unsigned int flags)
+long do_splice_to(struct file *in, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len,
+ unsigned int flags)
{
ssize_t (*splice_read)(struct file *, loff_t *,
struct pipe_inode_info *, size_t, unsigned int);
diff --git a/include/linux/namei.h b/include/linux/namei.h
index ec0f607..1438153 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -75,6 +75,9 @@ extern struct file *lookup_instantiate_filp(struct nameidata *nd, struct dentry
extern struct file *nameidata_to_filp(struct nameidata *nd, int flags);
extern void release_open_intent(struct nameidata *);

+extern struct dentry *lookup_hash(struct nameidata *nd);
+extern int __lookup_one_len(const char *name, struct qstr *this,
+ struct dentry *base, int len);
extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
extern struct dentry *lookup_one_noperm(const char *, struct dentry *);

diff --git a/include/linux/splice.h b/include/linux/splice.h
index 18e7c7c..8393b5c 100644
--- a/include/linux/splice.h
+++ b/include/linux/splice.h
@@ -82,4 +82,10 @@ extern ssize_t splice_to_pipe(struct pipe_inode_info *,
extern ssize_t splice_direct_to_actor(struct file *, struct splice_desc *,
splice_direct_actor *);

+extern long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
+ loff_t *ppos, size_t len, unsigned int flags);
+extern long do_splice_to(struct file *in, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len,
+ unsigned int flags);
+
#endif


Thanks
J. R. Okajima

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Mon, Dec 07, 2009 at 02:37:17PM +0900, hooanon05@yahoo.co.jp wrote:
>
> Greg KH:
> > Ok, if aufs relies on exports that Christoph is not going to accept,
> > then there's nothing I can do to add the code to the kernel.
> >
> > _unless_ the code will work if it is built in. What symbols are needed
> > by aufs, and is only to allow it to be built as a module, but not as a
> > built-in filesystem?
> >
> > If built-in will work, then it could work in staging, right?
>
> The word 'export' I use here might be incorrect.
> Strictly speaking, it is "make some functions global" instead of "export
> symbols to external module."
> Actually the aufs patches I sent to LKML were not to build aufs as a
> module. It supports CONFIG_AUFS_FS=y only.
> There exist another GIT tree to build aufs as a module.

Ok, thanks for the detailed responses. I guess this rules out aufs to
go into the drivers/staging/ tree, sorry.

thanks,

greg k-h

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team