Re: [ANNOUNCE] TCM/LIO v4.0.0-rc4 for 2.6.36-rc4

Re: [ANNOUNCE] TCM/LIO v4.0.0-rc4 for 2.6.36-rc4

[Nicholas A. Bellinger]

On Sat, 2010-09-18 at 13:00 +0900, FUJITA Tomonori wrote:
> On Fri, 17 Sep 2010 13:22:10 -0700
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> wrote:
> 
> > It is my great pleasure to announce that TCM/LIO v4.0.0-rc4 for v2.6.36-rc4 has
> > been tagged and pushed into lio-core-2.6.git/lio-4.0.  The last weeks have been
> > really very busy and many gracious thanks go out to all of the individuals who
> > made comments and helped bring together this v4.0.0-rc4 release.  A list of the
> > major changes includes:
> 
> Have you addressed all the non-SCSI obstacles to mainline inclusion?
> Sorry, I can't track TCM thread but I thought that you got some sysfs
> issues at least?

So the only remaining item outside of drivers/target/ code that needs to
be addressed for .37 is the symlink referencing counting bit.  This is
the case where a struct config_group with symlinks that use a
destination that is in a struct config_group *above* where the source
link struct config_group lives, and currently makes it impossible to
signal (from theconfigfs consumer perspective) the destination symlink
that the parent struct config_group is being dropped with rmdir().

Joel and I have been discussing potential resoultions here:

http://marc.info/?l=linux-fsdevel&m=128414860505481&w=2

but we have yet to come to a resolution, and the ->check_link() patch is
still in use in lio-core-2.6.git/lio-4.0 code.

The possibilities that have been discussed so far include:

*) Include the original struct config_item_operations->check_link()
patch and require the configfs customer to be aware of this case when
fs/configfs/symlink.c:configfs_unlink().  At this point this still works
OK for me, but I do acknowledge that making the configfs consumer aware
of this issue is really not the proper right long term solution.

*) Use refcounting for the symlinks inside of the configfs consumer.  I
asked Joel about how to do this in his last response, but I have not yet
heard back from him.   Joel, would you be so kind as to elaborate on
what you meant by this..?

*) Make fs/configfs/symlink.c code handle this specific "destination
link outside of parent struct config_group" symlink reference count case
internally instead of requiring configfs consumers be aware of the
issue.

At this point I am still leaning towards #3 (with Joel's blessing) as
the cleanest  long term solution, but I am still happy to persue #2 for
fabric independent configfs handlers target_core_fabric_configfs.c code
for the .37 merge.  I am still open suggestions (again, with Joel's
blessing) about how to get this item properly resolved.

> 
> If so, can you tell me where I can find reviewable patchset?

So the RFC cuts have been going into a seperate tree here:

http://git.kernel.org/?p=linux/kernel/git/nab/lio-4.0.git;a=summary

Mike has requested an RFC v2 for him to review TCM Core and TCM_Loop
v4.0.0-rc4 changes.  So I will be respinning this tree with the latest
changes from lio-core-2.6.git/lio-4.0 and re-posting in the next days.

> I really hope that you drop stuff from the patchset that isn't a must for
> target support (e.g. queuecommand lock stuff). If you keep adding
> something new to tha patchset, it's really difficult to review it.
> --

Indeed, I plan to keep the drop-host_lock stuff a logically seperate item,
and the TCM_Loop ->queuecommand() caller in the upcoming RFC v2 patches
will still contain the original host_lock unlock() -> do_work() -> lock()
optimization in use by many mainline LLDs today.  I will plan to send a
seperate patch to James depending how/when the drop-host_lock stuff is merged.

Many thanks for your comments Tomo-san!

--nab

Re: [ANNOUNCE] TCM/LIO v4.0.0-rc4 for 2.6.36-rc4

[Boaz Harrosh]

On 09/18/2010 10:32 PM, Nicholas A. Bellinger wrote:
> On Sat, 2010-09-18 at 13:00 +0900, FUJITA Tomonori wrote:
> So the RFC cuts have been going into a seperate tree here:
> 
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-4.0.git;a=summary
> 

This is the two weeks ago stuff, right. Where is the lio-core-2.6.git/ ?

> Mike has requested an RFC v2 for him to review TCM Core and TCM_Loop
> v4.0.0-rc4 changes.  So I will be respinning this tree with the latest
> changes from lio-core-2.6.git/lio-4.0 and re-posting in the next days.
> 

Me to. And a git tree and a git web, as well. I'll postpone any review
to that time.

Thanks
Boaz

Re: [ANNOUNCE] TCM/LIO v4.0.0-rc4 for 2.6.36-rc4

[Nicholas A. Bellinger]

On Sun, 2010-09-19 at 15:55 +0200, Boaz Harrosh wrote:
> On 09/18/2010 10:32 PM, Nicholas A. Bellinger wrote:
> > On Sat, 2010-09-18 at 13:00 +0900, FUJITA Tomonori wrote:
> > So the RFC cuts have been going into a seperate tree here:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/nab/lio-4.0.git;a=summary
> > 
> 
> This is the two weeks ago stuff, right. Where is the lio-core-2.6.git/ ?
> 
> > Mike has requested an RFC v2 for him to review TCM Core and TCM_Loop
> > v4.0.0-rc4 changes.  So I will be respinning this tree with the latest
> > changes from lio-core-2.6.git/lio-4.0 and re-posting in the next days.
> > 
> 
> Me to. And a git tree and a git web, as well. I'll postpone any review
> to that time.

Hi Boaz,

So as mentioned earlier, the main upstream branch where all of the
review changes have been moving through is located at
lio-core-2.6.git/lio-4.0:

http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=shortlog;h=refs/heads/lio-4.0

I will be doing a RFCv2 posting for TCM Core and TCM_Loop v4.0.0-rc4
with the very latest changes this week for Mike, Tomo-san and yourself
to further review.  This series will be in the usual one-file-per-commit
format and will be pushed these into a rfcv2-for-37 branch against
v2.6.36-rc4 in the seperate pristine lio-4.0.git tree mentioned above.

Also just FYI, the workflow I plan to use post-merge for TCM is to
continue to merge all changes in via the lio-core-2.6.git tree, and send
out pull requests for patches destined to mainline via a seperate
pristine tree + branches.

Best,

--nab