[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1806221537570.2402@nanos.tec.linutronix.de>
Date: Fri, 22 Jun 2018 15:39:16 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Al Viro <viro@...IV.linux.org.uk>
cc: David Howells <dhowells@...hat.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the tip tree with the vfs tree
On Fri, 22 Jun 2018, Al Viro wrote:
> On Fri, Jun 22, 2018 at 01:45:23PM +0100, David Howells wrote:
> > Reinette Chatre <reinette.chatre@...el.com> wrote:
> >
> > > Thomas and David, please let me know what I can do from my side to help
> > > with this.
> >
> > You could try basing on Al Viro's for-next tree which has the mount API
> > changes in it.
>
> Umm... That would be a massive headache for everyone involved; the changes
> in there have very little in common with what you are doing in rdt_mount(),
> so it might make sense to start with a minimal never-rebased branch that
> would
> * define rdt_pseudo_lock_init as 0
> * define rdt_pseudo_lock_release as empty
> * do the rdt_mount() part of a3dbd01e6c9d
> * have commit message along the lines of
> "hooks in rdt_mount() for rdt_pseudo_lock to use
>
> Functionally a no-op right now; the only reason for having that
> as a never-rebased branch to get rdt_pseudo_lock and mount series
> out of each other's hair"
>
> Base that on -rc1, then pull it into your rdt branch and David could pull the
> same into his.
Yes, that works.
Reinette, can you please look into creating that ordering. Then we just zap
the existing branch and redo it with this scheme.
Thanks,
tglx
Powered by blists - more mailing lists