linux-next: manual merge of the staging tree with the target-merge tree

linux-next: manual merge of the staging tree with the target-merge tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
merge for vhost level target fabric driver") from the target-merge tree
and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
the staging tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/Kconfig
index 67ec9fe,e3402d5..0000000
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
  
  source "drivers/staging/gdm72xx/Kconfig"
  
+ source "drivers/staging/csr/Kconfig"
+ 
+ source "drivers/staging/omap-thermal/Kconfig"
+ 
 +source "drivers/vhost/Kconfig.tcm"
 +
  endif # STAGING

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Greg KH]

On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> merge for vhost level target fabric driver") from the target-merge tree
> and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> the staging tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc drivers/staging/Kconfig
> index 67ec9fe,e3402d5..0000000
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
>   
>   source "drivers/staging/gdm72xx/Kconfig"
>   
> + source "drivers/staging/csr/Kconfig"
> + 
> + source "drivers/staging/omap-thermal/Kconfig"
> + 
>  +source "drivers/vhost/Kconfig.tcm"

Why is someone putting a non drivers/staging/ Kconfig file here in
drivers/staging/Kconfig?  That's not ok at all.

Target people, please just depend on CONFIG_STAGING if you want to do
that, but don't mess with files in the drivers/staging/ directory for no
good reason at all.

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

Hi Greg,

On Thu, 2012-07-19 at 16:55 -0700, Greg KH wrote:
> On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> > merge for vhost level target fabric driver") from the target-merge tree
> > and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> > the staging tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > 
> > diff --cc drivers/staging/Kconfig
> > index 67ec9fe,e3402d5..0000000
> > --- a/drivers/staging/Kconfig
> > +++ b/drivers/staging/Kconfig
> > @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
> >   
> >   source "drivers/staging/gdm72xx/Kconfig"
> >   
> > + source "drivers/staging/csr/Kconfig"
> > + 
> > + source "drivers/staging/omap-thermal/Kconfig"
> > + 
> >  +source "drivers/vhost/Kconfig.tcm"
> 
> Why is someone putting a non drivers/staging/ Kconfig file here in
> drivers/staging/Kconfig?  That's not ok at all.
> 
> Target people, please just depend on CONFIG_STAGING if you want to do
> that, but don't mess with files in the drivers/staging/ directory for no
> good reason at all.
> 

This was a request from MST (CC'ed) in order to have TCM_VHOST show up
under the staging configuration options..

If that's really not what should be done, I'm happy to drop this part
and just use CONFIG_STAGING again.

MST, is that OK..?

Thanks,

--nab

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Greg KH]

On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> Hi Greg,
> 
> On Thu, 2012-07-19 at 16:55 -0700, Greg KH wrote:
> > On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > > 
> > > Today's linux-next merge of the staging tree got a conflict in
> > > drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> > > merge for vhost level target fabric driver") from the target-merge tree
> > > and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> > > the staging tree.
> > > 
> > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > necessary.
> > > -- 
> > > Cheers,
> > > Stephen Rothwell                    sfr@canb.auug.org.au
> > > 
> > > diff --cc drivers/staging/Kconfig
> > > index 67ec9fe,e3402d5..0000000
> > > --- a/drivers/staging/Kconfig
> > > +++ b/drivers/staging/Kconfig
> > > @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
> > >   
> > >   source "drivers/staging/gdm72xx/Kconfig"
> > >   
> > > + source "drivers/staging/csr/Kconfig"
> > > + 
> > > + source "drivers/staging/omap-thermal/Kconfig"
> > > + 
> > >  +source "drivers/vhost/Kconfig.tcm"
> > 
> > Why is someone putting a non drivers/staging/ Kconfig file here in
> > drivers/staging/Kconfig?  That's not ok at all.
> > 
> > Target people, please just depend on CONFIG_STAGING if you want to do
> > that, but don't mess with files in the drivers/staging/ directory for no
> > good reason at all.
> > 
> 
> This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> under the staging configuration options..

If you really want it to show up there, then send me a patch adding the
code to drivers/staging/.  Otherwise it really makes no sense.

> If that's really not what should be done, I'm happy to drop this part
> and just use CONFIG_STAGING again.

Why are you wanting to depend on CONFIG_STAGING in the first place?
What is wrong with the code that it can't be merged "properly" now?
Don't use CONFIG_STAGING as a "crutch" unless you really need it.

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

On Fri, 2012-07-20 at 11:03 -0700, Greg KH wrote:
> On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> > Hi Greg,
> > 

<SNIP>

> -- a/drivers/staging/Kconfig
> > > > +++ b/drivers/staging/Kconfig
> > > > @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
> > > >   
> > > >   source "drivers/staging/gdm72xx/Kconfig"
> > > >   
> > > > + source "drivers/staging/csr/Kconfig"
> > > > + 
> > > > + source "drivers/staging/omap-thermal/Kconfig"
> > > > + 
> > > >  +source "drivers/vhost/Kconfig.tcm"
> > > 
> > > Why is someone putting a non drivers/staging/ Kconfig file here in
> > > drivers/staging/Kconfig?  That's not ok at all.
> > > 
> > > Target people, please just depend on CONFIG_STAGING if you want to do
> > > that, but don't mess with files in the drivers/staging/ directory for no
> > > good reason at all.
> > > 
> > 
> > This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> > under the staging configuration options..
> 
> If you really want it to show up there, then send me a patch adding the
> code to drivers/staging/.  Otherwise it really makes no sense.
> 

<nod>

> > If that's really not what should be done, I'm happy to drop this part
> > and just use CONFIG_STAGING again.
> 
> Why are you wanting to depend on CONFIG_STAGING in the first place?
> What is wrong with the code that it can't be merged "properly" now?
> Don't use CONFIG_STAGING as a "crutch" unless you really need it.
> 

This was a request by MST because we've not agreed on the upstream
userspace bits yet, so he asked to mark this code as STAGING so that it
can be removed if we can't end up agreeing with the QEMU folks.

At this point I don't see why we can't work out of userspace bits, but
MST preferred adding the STAGING bit for tcm_vhost to just to be sure.

--nab 

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Michael S. Tsirkin]

On Fri, Jul 20, 2012 at 11:03:58AM -0700, Greg KH wrote:
> On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> > Hi Greg,
> > 
> > On Thu, 2012-07-19 at 16:55 -0700, Greg KH wrote:
> > > On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> > > > Hi Greg,
> > > > 
> > > > Today's linux-next merge of the staging tree got a conflict in
> > > > drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> > > > merge for vhost level target fabric driver") from the target-merge tree
> > > > and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> > > > the staging tree.
> > > > 
> > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > > > -- 
> > > > Cheers,
> > > > Stephen Rothwell                    sfr@canb.auug.org.au
> > > > 
> > > > diff --cc drivers/staging/Kconfig
> > > > index 67ec9fe,e3402d5..0000000
> > > > --- a/drivers/staging/Kconfig
> > > > +++ b/drivers/staging/Kconfig
> > > > @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
> > > >   
> > > >   source "drivers/staging/gdm72xx/Kconfig"
> > > >   
> > > > + source "drivers/staging/csr/Kconfig"
> > > > + 
> > > > + source "drivers/staging/omap-thermal/Kconfig"
> > > > + 
> > > >  +source "drivers/vhost/Kconfig.tcm"
> > > 
> > > Why is someone putting a non drivers/staging/ Kconfig file here in
> > > drivers/staging/Kconfig?  That's not ok at all.
> > > 
> > > Target people, please just depend on CONFIG_STAGING if you want to do
> > > that, but don't mess with files in the drivers/staging/ directory for no
> > > good reason at all.
> > > 
> > 
> > This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> > under the staging configuration options..
> 
> If you really want it to show up there, then send me a patch adding the
> code to drivers/staging/.  Otherwise it really makes no sense.
> 
> > If that's really not what should be done, I'm happy to drop this part
> > and just use CONFIG_STAGING again.
> 
> Why are you wanting to depend on CONFIG_STAGING in the first place?
> What is wrong with the code that it can't be merged "properly" now?
> Don't use CONFIG_STAGING as a "crutch" unless you really need it.
> 
> thanks,
> 
> greg k-h

It's very similar to how it was with nouveau: we are not sure
we can commit to the userspace ABI yet.

Most importantly, it still seems not 100% clear whether this driver will
have major userspace using it. And if not, it would be very hard to
support a driver when recent userspace does not use it in the end.

At the moment arguments on upstream mailing list seem to be
a bit circular: there's no module in upstream kernel so
userspace does not want to accept the patches.

If we put enabling this driver in staging, then it works out in one of
two ways
- userspace starts using it then this effectively freezes the ABI and
  we move it out of staging next release
- no userspace uses it and we drop it completely or rework ABI

On the other hand, it is marginally better to not want code in staging
for two reasons:
- there are dependencies between this code and other code in
  drivers/vhost which are easier for me to handle if it's all
  in one place
- a bit easier to track history if we do not move code

What do you think?

-- 
MST

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

Hi Greg,

On Fri, 2012-07-20 at 21:42 +0300, Michael S. Tsirkin wrote:
> On Fri, Jul 20, 2012 at 11:03:58AM -0700, Greg KH wrote:
> > On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> > > Hi Greg,
> > > 

<SNIP>

> > > This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> > > under the staging configuration options..
> > 
> > If you really want it to show up there, then send me a patch adding the
> > code to drivers/staging/.  Otherwise it really makes no sense.
> > 
> > > If that's really not what should be done, I'm happy to drop this part
> > > and just use CONFIG_STAGING again.
> > 
> > Why are you wanting to depend on CONFIG_STAGING in the first place?
> > What is wrong with the code that it can't be merged "properly" now?
> > Don't use CONFIG_STAGING as a "crutch" unless you really need it.
> > 
> > thanks,
> > 
> > greg k-h
> 
> It's very similar to how it was with nouveau: we are not sure
> we can commit to the userspace ABI yet.
> 
> Most importantly, it still seems not 100% clear whether this driver will
> have major userspace using it. And if not, it would be very hard to
> support a driver when recent userspace does not use it in the end.
> 
> At the moment arguments on upstream mailing list seem to be
> a bit circular: there's no module in upstream kernel so
> userspace does not want to accept the patches.
> 
> If we put enabling this driver in staging, then it works out in one of
> two ways
> - userspace starts using it then this effectively freezes the ABI and
>   we move it out of staging next release
> - no userspace uses it and we drop it completely or rework ABI
> 
> On the other hand, it is marginally better to not want code in staging
> for two reasons:
> - there are dependencies between this code and other code in
>   drivers/vhost which are easier for me to handle if it's all
>   in one place
> - a bit easier to track history if we do not move code
> 
> What do you think?
> 

After chatting with MST off-list he asked for a RFC-v4 series with one
extra change to vhost.h wrt the vhost-scsi ioctl defs.  He also said he
is OK with taking the first three patches -v4 through vhost.git and
letting staging take tcm_vhost.   Of course we'd need staging to depend
on vhost for that to work <cough> (compile) properly..  ;)

I'd like to re-spin -v4 this evening so that he can review + ACK the
full series before leaving for holiday tomorrow, so please let me know
what you'd prefer to do here.

So that said, do you prefer having tcm_vhost moved into drivers/staging
for -v4, or should we just be using a CONFIG_STAGING tag in
drivers/vhost/ and be done with it..?

Thank you!

--nab

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Greg KH]

On Fri, Jul 20, 2012 at 09:42:28PM +0300, Michael S. Tsirkin wrote:
> On Fri, Jul 20, 2012 at 11:03:58AM -0700, Greg KH wrote:
> > On Fri, Jul 20, 2012 at 10:52:58AM -0700, Nicholas A. Bellinger wrote:
> > > Hi Greg,
> > > 
> > > On Thu, 2012-07-19 at 16:55 -0700, Greg KH wrote:
> > > > On Thu, Jul 19, 2012 at 02:53:01PM +1000, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > Today's linux-next merge of the staging tree got a conflict in
> > > > > drivers/staging/Kconfig between commit d0146d396bfa ("tcm_vhost: Initial
> > > > > merge for vhost level target fabric driver") from the target-merge tree
> > > > > and commit 15a4bc17b7f4 ("Staging: add CSR Wifi "os helper" module") from
> > > > > the staging tree.
> > > > > 
> > > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > > necessary.
> > > > > -- 
> > > > > Cheers,
> > > > > Stephen Rothwell                    sfr@canb.auug.org.au
> > > > > 
> > > > > diff --cc drivers/staging/Kconfig
> > > > > index 67ec9fe,e3402d5..0000000
> > > > > --- a/drivers/staging/Kconfig
> > > > > +++ b/drivers/staging/Kconfig
> > > > > @@@ -132,6 -132,8 +132,10 @@@ source "drivers/staging/ipack/Kconfig
> > > > >   
> > > > >   source "drivers/staging/gdm72xx/Kconfig"
> > > > >   
> > > > > + source "drivers/staging/csr/Kconfig"
> > > > > + 
> > > > > + source "drivers/staging/omap-thermal/Kconfig"
> > > > > + 
> > > > >  +source "drivers/vhost/Kconfig.tcm"
> > > > 
> > > > Why is someone putting a non drivers/staging/ Kconfig file here in
> > > > drivers/staging/Kconfig?  That's not ok at all.
> > > > 
> > > > Target people, please just depend on CONFIG_STAGING if you want to do
> > > > that, but don't mess with files in the drivers/staging/ directory for no
> > > > good reason at all.
> > > > 
> > > 
> > > This was a request from MST (CC'ed) in order to have TCM_VHOST show up
> > > under the staging configuration options..
> > 
> > If you really want it to show up there, then send me a patch adding the
> > code to drivers/staging/.  Otherwise it really makes no sense.
> > 
> > > If that's really not what should be done, I'm happy to drop this part
> > > and just use CONFIG_STAGING again.
> > 
> > Why are you wanting to depend on CONFIG_STAGING in the first place?
> > What is wrong with the code that it can't be merged "properly" now?
> > Don't use CONFIG_STAGING as a "crutch" unless you really need it.
> > 
> > thanks,
> > 
> > greg k-h
> 
> It's very similar to how it was with nouveau: we are not sure
> we can commit to the userspace ABI yet.

Then you are in trouble :)

> Most importantly, it still seems not 100% clear whether this driver will
> have major userspace using it. And if not, it would be very hard to
> support a driver when recent userspace does not use it in the end.
> 
> At the moment arguments on upstream mailing list seem to be
> a bit circular: there's no module in upstream kernel so
> userspace does not want to accept the patches.
> 
> If we put enabling this driver in staging, then it works out in one of
> two ways
> - userspace starts using it then this effectively freezes the ABI and
>   we move it out of staging next release
> - no userspace uses it and we drop it completely or rework ABI
> 
> On the other hand, it is marginally better to not want code in staging
> for two reasons:
> - there are dependencies between this code and other code in
>   drivers/vhost which are easier for me to handle if it's all
>   in one place

If there are going to be lots of dependancies, then I don't want it in
drivers/staging/ as it doesn't belong there, it belongs cleaned up and
in the "real" place.

> - a bit easier to track history if we do not move code

git preserves this, don't worry about that at all.

So, if this code really does depend on core vhost changes that are going
to be happening over time, I would not recommend it being in
drivers/staging/ as you are right, you are going to have a hard time
syncing with me.

But don't think that by somehow marking the driver with CONFIG_STAGING
that you get a free pass on the "we are going to break the userspace
api", that's not ok.  Be careful about this.  Yes, it's tough, and it's
a "chicken and egg" problem like you mention above, I know.

sorry,

greg k-h

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

On Sat, 2012-07-21 at 19:07 -0700, Greg KH wrote:
> On Fri, Jul 20, 2012 at 09:42:28PM +0300, Michael S. Tsirkin wrote:

<SNIP>

> > It's very similar to how it was with nouveau: we are not sure
> > we can commit to the userspace ABI yet.
> 
> Then you are in trouble :)
> 

I agree with MST here that tcm_vhost needs a clear way to indicate that
ABI changes are likely to occur in transmit from staging -> post-staging
status.  

> > Most importantly, it still seems not 100% clear whether this driver will
> > have major userspace using it. And if not, it would be very hard to
> > support a driver when recent userspace does not use it in the end.
> > 
> > At the moment arguments on upstream mailing list seem to be
> > a bit circular: there's no module in upstream kernel so
> > userspace does not want to accept the patches.
> > 
> > If we put enabling this driver in staging, then it works out in one of
> > two ways
> > - userspace starts using it then this effectively freezes the ABI and
> >   we move it out of staging next release
> > - no userspace uses it and we drop it completely or rework ABI
> > 
> > On the other hand, it is marginally better to not want code in staging
> > for two reasons:
> > - there are dependencies between this code and other code in
> >   drivers/vhost which are easier for me to handle if it's all
> >   in one place
> 
> If there are going to be lots of dependancies, then I don't want it in
> drivers/staging/ as it doesn't belong there, it belongs cleaned up and
> in the "real" place.
> 
> > - a bit easier to track history if we do not move code
> 
> git preserves this, don't worry about that at all.
> 
> So, if this code really does depend on core vhost changes that are going
> to be happening over time, I would not recommend it being in
> drivers/staging/ as you are right, you are going to have a hard time
> syncing with me.
> 

So Linus has merged target-pending/for-next this afternoon, so now we
are just waiting on net-next to hit mainline with the vhost patches
already ACK'ed by MST.  Hopefully that makes things easier for you to
considering taking tcm_vhost upstream via staging.  ;)

Also, MST asked for an RFC-v5 for the initial merge commit with some
minor debug wrapper changes that will be going out next week.  This will
include a move into drivers/staging/tcm_vhost/ against a rebased
staging.git patch with the necessary -rc0 mainline dependencies.

Please let me know if your OK with this, otherwise I'll just plan to
keep -v5 against target-pending/for-next-merge for now, and send a GIT
PULL after MST gets back from holiday on the 29th -> 30th.

> But don't think that by somehow marking the driver with CONFIG_STAGING
> that you get a free pass on the "we are going to break the userspace
> api", that's not ok.  Be careful about this.  Yes, it's tough, and it's
> a "chicken and egg" problem like you mention above, I know.
> 

After sleeping on this, I'm wondering if there is not something else we
could do at the QEMU level to require an explicit 'development=1' flag
in order to use vhost-scsi while tcm_vhost is still marked as staging
code..?

QEMU folks, would you be open to something like this..?

Thank you,

--nab

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Greg KH]

On Sun, Jul 22, 2012 at 02:44:23PM -0700, Nicholas A. Bellinger wrote:
> So Linus has merged target-pending/for-next this afternoon, so now we
> are just waiting on net-next to hit mainline with the vhost patches
> already ACK'ed by MST.  Hopefully that makes things easier for you to
> considering taking tcm_vhost upstream via staging.  ;)
> 
> Also, MST asked for an RFC-v5 for the initial merge commit with some
> minor debug wrapper changes that will be going out next week.  This will
> include a move into drivers/staging/tcm_vhost/ against a rebased
> staging.git patch with the necessary -rc0 mainline dependencies.
> 
> Please let me know if your OK with this, otherwise I'll just plan to
> keep -v5 against target-pending/for-next-merge for now, and send a GIT
> PULL after MST gets back from holiday on the 29th -> 30th.

I have no idea what any of the above three paragraphs are asking for, or
talking about, sorry.

Note, the merge window is closed for taking new stuff into the staging
tree.  If it isn't already in my staging-next tree, it isn't going to go
into 3.6 unless it's bug fixes, sorry.  How about we figure all of this
out after 3.6-rc1 is out so we can understand what is going on for 3.7?

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the target-merge tree

[Nicholas A. Bellinger]

On Mon, 2012-07-23 at 08:16 -0700, Greg KH wrote:
> On Sun, Jul 22, 2012 at 02:44:23PM -0700, Nicholas A. Bellinger wrote:
> > So Linus has merged target-pending/for-next this afternoon, so now we
> > are just waiting on net-next to hit mainline with the vhost patches
> > already ACK'ed by MST.  Hopefully that makes things easier for you to
> > considering taking tcm_vhost upstream via staging.  ;)
> > 
> > Also, MST asked for an RFC-v5 for the initial merge commit with some
> > minor debug wrapper changes that will be going out next week.  This will
> > include a move into drivers/staging/tcm_vhost/ against a rebased
> > staging.git patch with the necessary -rc0 mainline dependencies.
> > 
> > Please let me know if your OK with this, otherwise I'll just plan to
> > keep -v5 against target-pending/for-next-merge for now, and send a GIT
> > PULL after MST gets back from holiday on the 29th -> 30th.
> 
> I have no idea what any of the above three paragraphs are asking for, or
> talking about, sorry.
> 
> Note, the merge window is closed for taking new stuff into the staging
> tree.  If it isn't already in my staging-next tree, it isn't going to go
> into 3.6 unless it's bug fixes, sorry.

In that case, I'll just keep tcm_vhost in drivers/vhost/ for now and
await MST's return to determine if he's willing to ACK this round (via
target-pending) for an initial merge.

> How about we figure all of this
> out after 3.6-rc1 is out so we can understand what is going on for 3.7?
> 

I'd like to try to avoid slipping to v3.7 if possible, as we'll have the
necessary dependencies in mainline over the next days once net-next is
merged.  It's also self-contained driver that does not effect existing
code (aside from what's already been ACK'ed), so risk is very low..

--nab