aufs on staging

[Greg KH]

On Mon, Dec 07, 2009 at 01:27:25PM +0900, hooanon05 at 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 at 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