Greetings all,
It is my pleasure to announce TCM/LIO v4.0.0-rc6 for v2.6.37-rc6 has
been tagged and pushed into lio-core-2.6.git/lio-4.0 and master
branches. It has been almost two months since the last -rc5 for .36-rc8
was released, and since that time a number of refactoring and cleanup
patch series from Christoph Hellwig have been merged to reduced the
target core logic and backend drivers by nearly ~4200 LOC!
A big thanks to Christoph for jumping on a number of areas that have
needed attention in target_core_transport.c for some time, and for being
the very first 'third party' kernel developer to pull ahead in the
TCM/LIO patch ranking for a single TCM/LIO release. It was a good
race, and hch did very much earn his victory for this round (41 vs. 36)
in the final rankings attached below.
Also, I am proud to announce this is the first release of Target Core
code running with a publically available HW target fabric module. The
tcm_qla2xxx and qla2xxx LLD code is now available from the
lio-core-2.6.git/tcm_qla2xxx branch, and more information about the
recent Alpha -> BETA release and the ongoing developers are available
here:
http://www.linux-iscsi.org/index.php/Qlogic
And the initial RFC patches here:
http://marc.info/?l=linux-scsi&m=129244523223528&w=2
There have also been a number of important bugfixes that have gone into
this release, so for folks running on earlier v4.0 code please consider
upgrading now.. Here is a brief list of the critical fixes from below:
*) tcm/iblock: Fix bio-set leak during bio exception handling (nab)
*) tcm/pscsi: Fix incorrect usage of head_of_queue with
blk_execute_rq_nowait() (boaz)
*) tcm/pscsi: Fix failure case for __pscsi_map_task_SG() (nab)
*) tcm: Fix OOPs w/ task->task_sg_bidi[] for non BIDI operation (kiran)
*) target: Fix tfo->write_pending() fabric callback ordering (nab,
kiran, and others)
There has also been work in a number of branches where work is ongoing,
and not mentioned in the final stats below. This includes Tomo-san's
work with the ibmvscsis module for IBM POWER VSCSI in branch
tcm_ibmvstgt, and Kiran Patil for his recent work in the
tcm_fc_ddp_offload branch for adding offload support for 10 Gb/sec Intel
NICs with TCM_FC/OpenFCOE target code that will be merged into TCM/LIO
upstream in a future release.
Kiran also found and fixed his first bug in upstream Target code, and
helped squash another long standing (since v2.x day) issue wrt to
interrupt context usage required for HW target mode within the
transport_generic_write_pending() callback. He will be continuing to
test and improve the TCM_FC/OpenFCoE code on Intel 10 Gb/sec hardware,
and maintaining the DDP offload pieces for FCoE within
lio-core-2.6.git/tcm_fc_ddp_offload branch on kernel.org. Thank you and
great work Kiran!
At this point v4.0 development will be slowing down, as I will only be
accepting critical fixes at this point for v4.0.0-rc7 as we move into
the testing and validation phase for .38 mainline code. So please
folks, if anyone has immediate issues for v4.0 that need to be
considered, please make myself and other core target devels aware and we
will do our best to get them addressed.
Best Regards,
--nab
Christoph Hellwig (41):
target: remove never changing indirections in se_cmd
target: remove activate_device/deactivate_device
target: remove SHUTDOWN_SIGS
target: remove transport_generic_map_buffers_to_tasks
target: clean up transport_subsystem_register
target: remove dead blockdevice claim/release code
target: remove transport_generic_free_device
target: remove unused split_cdb_RW_* handlers
target: remove dead call to transport_emulate_control_cdb in rd
driver
target: split CDB emulation out of target_core_transport.c
target: take advantage of REQ_FUA in the iblock backend
target: clean up cache flush / FUA handling in the file backend
target: fix block limits VPD emulation
target: remove unused exports
target: simplify and speed up task allocation
target: kill CONFIG_TCM_DEBUG_DEV
target: remove dead DF_* flags
target: Kconfig fixes
target: rename Kbuild files to Makefile
target: move iovec handling into the iscsi code
target: simplify memory allocation
target: simplify se_task mapping
target-stgt: fix initializaiton
target: remove dead backend methods
target: simplify cmd to task mapping
target: consolidate se_global externs
target: remove core_get_hba/core_put_hba
target: remove se_hba_cache
target: simplify hba allocation and freeing
target: simplify subsystem registration and lookup
target: remove the unused type field in struct se_subsystem_api
target: mark the transport_complete method optional
target: remove some iscsi leftovers in core code
target: remove unused snapshot attributes
target-pscsi: query tape blocksize using scsi_execute_req
target: always get capacity from ->get_blocks
target-pscsi: get inquiry data using scsi_execute_req
target: remove passthrough support
target: remove unused get_dma_length subsystem method
target: always assign t_task_lba in transport_generic_cmd_sequencer
target: always assign se_cmd flags in transport_generic_cmd_sequencer
Kiran Patil (1):
tcm: Fix OOPs w/ task->task_sg_bidi[] for non BIDI operation
Nicholas Bellinger (36):
tcm: Fix missing TABs in drivers/target/Kconfig
tcm/iblock: Fix bio-set leak during bio exception handling
tcm/iblock: Update blkdev_issue_flush() parameter usage
lio-target: Drop init_MUTEX*() wrapper usage
tcm: Add transport_generic_handle_cdb_map() wrapper
tcm: Move special PASSTHROUGH_CONTIG_TO_SG handling into internal TFO
callbacks
tcm: Drop ->max_cdb_len from struct se_dev_limits
tcm/pscsi: Fix incorrect usage of head_of_queue with
blk_execute_rq_nowait()
tcm/pscsi: Drop unnecessary struct pscsi_plugin_task->pscsi_req_bidi
tcm/pscsi: Remove legacy struct scsi_device->sector_size workaround
for TYPE_DISK
tcm/pscsi: Fix failure case for __pscsi_map_task_SG()
tcm: Drop legacy struct se_subsystem_api->get_dev_info() caller
tcm: Convert backstore ->set_configfs_dev_params() to use parser.h
tcm: Convert target_core_dev_pr_store_attr_res_aptpl_metadata() to
use parser.h
tcm: drop transport_check_dev_params_delim()
tcm/configfs: Rename target_core_hba_group_ops callers
tcm_loop: Drop legacy host_lock usage in SHT->queuecommand() caller
tcm: Add missing NULL match_table_t entries
tcm: Drop unused DF_TRANSPORT_DMA_ALLOC caller
target: fix conversion spec warning for sizeof() usage
tcm_loop: Convert tcm_loop_queuecommand() to new parameter usage.
target: simplify cmd to task mapping
target: mark as much as possible static
target: Add proper cast for sizeof() usage
target: Fix up function pointer conditionals in
transport_map_control_cmd_to_task()
target: Push down iovec allocation into iSCSI target code
target: Fix fallthrough bug for SAI READ_CAPACITY_16
target: remove struct se_transform_info
target-pscsi: Fix incorrect scsi_execute_req() usage
target: Convert transport_dev_end_lba() to ->get_blocks()
target-ramdisk: Add missing ->get_blocks for rd_mcp_template
target: Remove dump_stack() for demo-mode LUN shutdown
target: Fix tfo->write_pending() fabric callback ordering
target: Convert se_nacl->nacl_sess_lock to use spin_lock_irq()
target: Add debug wrappers for transport_do_task_sg_chain
lio-core v4.0.0-rc6
drivers/target/Kbuild | 34 -
drivers/target/Kconfig | 47 +-
drivers/target/Makefile | 31 +
drivers/target/lio-target/Kbuild | 37 -
drivers/target/lio-target/Kconfig | 31 +-
drivers/target/lio-target/Makefile | 36 +
drivers/target/lio-target/iscsi_target.c | 506 ++-
drivers/target/lio-target/iscsi_target_configfs.c | 6 +-
drivers/target/lio-target/iscsi_target_core.h | 6 +-
drivers/target/lio-target/iscsi_target_login.c | 24 +-
drivers/target/lio-target/iscsi_target_mib.h | 1 -
drivers/target/lio-target/iscsi_target_tpg.c | 4 +-
drivers/target/lio-target/iscsi_target_util.c | 32 +-
drivers/target/lio-target/iscsi_target_util.h | 38 +-
drivers/target/lio-target/iscsi_target_version.h | 2 +-
drivers/target/lio-target/iscsi_thread_queue.c | 28 +-
drivers/target/target_core_alua.c | 48 +-
drivers/target/target_core_alua.h | 16 -
drivers/target/target_core_cdb.c | 1131 +++++
drivers/target/target_core_configfs.c | 534 +--
drivers/target/target_core_device.c | 180 +-
drivers/target/target_core_fabric_lib.c | 8 +-
drivers/target/target_core_file.c | 634 +---
drivers/target/target_core_file.h | 33 +-
drivers/target/target_core_hba.c | 190 +-
drivers/target/target_core_hba.h | 11 +-
drivers/target/target_core_iblock.c | 483 +--
drivers/target/target_core_iblock.h | 8 +-
drivers/target/target_core_mib.c | 5 +-
drivers/target/target_core_mib.h | 2 -
drivers/target/target_core_pr.c | 22 +-
drivers/target/target_core_pscsi.c | 742 ++--
drivers/target/target_core_pscsi.h | 10 +-
drivers/target/target_core_rd.c | 477 +--
drivers/target/target_core_rd.h | 20 +-
drivers/target/target_core_scdb.c | 53 -
drivers/target/target_core_scdb.h | 5 -
drivers/target/target_core_stgt.c | 480 +--
drivers/target/target_core_stgt.h | 7 +-
drivers/target/target_core_tmr.c | 18 +-
drivers/target/target_core_tpg.c | 6 +-
drivers/target/target_core_transport.c | 4773 ++++-----------------
drivers/target/tcm_fc/Kbuild | 16 -
drivers/target/tcm_fc/Kconfig | 5 +-
drivers/target/tcm_fc/Makefile | 15 +
drivers/target/tcm_fc/tfc_cmd.c | 9 +-
drivers/target/tcm_fc/tfc_conf.c | 2 -
drivers/target/tcm_loop/Kbuild | 11 -
drivers/target/tcm_loop/Kconfig | 16 +-
drivers/target/tcm_loop/Makefile | 11 +
drivers/target/tcm_loop/tcm_loop_fabric.c | 21 -
drivers/target/tcm_loop/tcm_loop_fabric_scsi.c | 25 +-
include/target/target_core_base.h | 190 +-
include/target/target_core_configfs.h | 5 -
include/target/target_core_device.h | 12 -
include/target/target_core_tpg.h | 4 -
include/target/target_core_transport.h | 267 +--
57 files changed, 3788 insertions(+), 7580 deletions(-)
On Thu, 2010-12-16 at 19:47 -0800, Nicholas A. Bellinger wrote:
> Greetings all,
>
> It is my pleasure to announce TCM/LIO v4.0.0-rc6 for v2.6.37-rc6 has
> been tagged and pushed into lio-core-2.6.git/lio-4.0 and master
> branches. It has been almost two months since the last -rc5 for .36-rc8
> was released, and since that time a number of refactoring and cleanup
> patch series from Christoph Hellwig have been merged to reduced the
> target core logic and backend drivers by nearly ~4200 LOC!
>
> A big thanks to Christoph for jumping on a number of areas that have
> needed attention in target_core_transport.c for some time, and for being
> the very first 'third party' kernel developer to pull ahead in the
> TCM/LIO patch ranking for a single TCM/LIO release. It was a good
> race, and hch did very much earn his victory for this round (41 vs. 36)
> in the final rankings attached below.
>
> Also, I am proud to announce this is the first release of Target Core
> code running with a publically available HW target fabric module. The
> tcm_qla2xxx and qla2xxx LLD code is now available from the
> lio-core-2.6.git/tcm_qla2xxx branch, and more information about the
> recent Alpha -> BETA release and the ongoing developers are available
> here:
>
> http://www.linux-iscsi.org/index.php/Qlogic
>
> And the initial RFC patches here:
>
> http://marc.info/?l=linux-scsi&m=129244523223528&w=2
>
> There have also been a number of important bugfixes that have gone into
> this release, so for folks running on earlier v4.0 code please consider
> upgrading now.. Here is a brief list of the critical fixes from below:
>
> *) tcm/iblock: Fix bio-set leak during bio exception handling (nab)
>
> *) tcm/pscsi: Fix incorrect usage of head_of_queue with
> blk_execute_rq_nowait() (boaz)
>
> *) tcm/pscsi: Fix failure case for __pscsi_map_task_SG() (nab)
>
> *) tcm: Fix OOPs w/ task->task_sg_bidi[] for non BIDI operation (kiran)
>
> *) target: Fix tfo->write_pending() fabric callback ordering (nab,
> kiran, and others)
>
> There has also been work in a number of branches where work is ongoing,
> and not mentioned in the final stats below. This includes Tomo-san's
> work with the ibmvscsis module for IBM POWER VSCSI in branch
> tcm_ibmvstgt, and Kiran Patil for his recent work in the
> tcm_fc_ddp_offload branch for adding offload support for 10 Gb/sec Intel
> NICs with TCM_FC/OpenFCOE target code that will be merged into TCM/LIO
> upstream in a future release.
>
> Kiran also found and fixed his first bug in upstream Target code, and
> helped squash another long standing (since v2.x day) issue wrt to
> interrupt context usage required for HW target mode within the
> transport_generic_write_pending() callback. He will be continuing to
> test and improve the TCM_FC/OpenFCoE code on Intel 10 Gb/sec hardware,
> and maintaining the DDP offload pieces for FCoE within
> lio-core-2.6.git/tcm_fc_ddp_offload branch on kernel.org. Thank you and
> great work Kiran!
>
> At this point v4.0 development will be slowing down, as I will only be
> accepting critical fixes at this point for v4.0.0-rc7 as we move into
> the testing and validation phase for .38 mainline code. So please
> folks, if anyone has immediate issues for v4.0 that need to be
> considered, please make myself and other core target devels aware and we
> will do our best to get them addressed.
OK, I think this has reached the stage where it's been polished enough
outside mainline to the point where we can complete any remaining todo
items in-tree.
So lets begin merging with the minimal target core and the TCM_Loop as
two separate commits. I think the target core may just fit under the
reflector mail length limits, but if not, you can send it as multiple
patches and I'll recombine them.
Thanks,
James
James Bottomley, on 12/17/2010 06:22 PM wrote:
> On Thu, 2010-12-16 at 19:47 -0800, Nicholas A. Bellinger wrote:
>> Greetings all,
>>
>> It is my pleasure to announce TCM/LIO v4.0.0-rc6 for v2.6.37-rc6 has
>> been tagged and pushed into lio-core-2.6.git/lio-4.0 and master
>> branches. It has been almost two months since the last -rc5 for .36-rc8
>> was released, and since that time a number of refactoring and cleanup
>> patch series from Christoph Hellwig have been merged to reduced the
>> target core logic and backend drivers by nearly ~4200 LOC!
>>
>> A big thanks to Christoph for jumping on a number of areas that have
>> needed attention in target_core_transport.c for some time, and for being
>> the very first 'third party' kernel developer to pull ahead in the
>> TCM/LIO patch ranking for a single TCM/LIO release. It was a good
>> race, and hch did very much earn his victory for this round (41 vs. 36)
>> in the final rankings attached below.
>>
>> Also, I am proud to announce this is the first release of Target Core
>> code running with a publically available HW target fabric module. The
>> tcm_qla2xxx and qla2xxx LLD code is now available from the
>> lio-core-2.6.git/tcm_qla2xxx branch, and more information about the
>> recent Alpha -> BETA release and the ongoing developers are available
>> here:
>>
>> http://www.linux-iscsi.org/index.php/Qlogic
>>
>> And the initial RFC patches here:
>>
>> http://marc.info/?l=linux-scsi&m=129244523223528&w=2
>>
>> There have also been a number of important bugfixes that have gone into
>> this release, so for folks running on earlier v4.0 code please consider
>> upgrading now.. Here is a brief list of the critical fixes from below:
>>
>> *) tcm/iblock: Fix bio-set leak during bio exception handling (nab)
>>
>> *) tcm/pscsi: Fix incorrect usage of head_of_queue with
>> blk_execute_rq_nowait() (boaz)
>>
>> *) tcm/pscsi: Fix failure case for __pscsi_map_task_SG() (nab)
>>
>> *) tcm: Fix OOPs w/ task->task_sg_bidi[] for non BIDI operation (kiran)
>>
>> *) target: Fix tfo->write_pending() fabric callback ordering (nab,
>> kiran, and others)
>>
>> There has also been work in a number of branches where work is ongoing,
>> and not mentioned in the final stats below. This includes Tomo-san's
>> work with the ibmvscsis module for IBM POWER VSCSI in branch
>> tcm_ibmvstgt, and Kiran Patil for his recent work in the
>> tcm_fc_ddp_offload branch for adding offload support for 10 Gb/sec Intel
>> NICs with TCM_FC/OpenFCOE target code that will be merged into TCM/LIO
>> upstream in a future release.
>>
>> Kiran also found and fixed his first bug in upstream Target code, and
>> helped squash another long standing (since v2.x day) issue wrt to
>> interrupt context usage required for HW target mode within the
>> transport_generic_write_pending() callback. He will be continuing to
>> test and improve the TCM_FC/OpenFCoE code on Intel 10 Gb/sec hardware,
>> and maintaining the DDP offload pieces for FCoE within
>> lio-core-2.6.git/tcm_fc_ddp_offload branch on kernel.org. Thank you and
>> great work Kiran!
>>
>> At this point v4.0 development will be slowing down, as I will only be
>> accepting critical fixes at this point for v4.0.0-rc7 as we move into
>> the testing and validation phase for .38 mainline code. So please
>> folks, if anyone has immediate issues for v4.0 that need to be
>> considered, please make myself and other core target devels aware and we
>> will do our best to get them addressed.
>
> OK, I think this has reached the stage where it's been polished enough
> outside mainline to the point where we can complete any remaining todo
> items in-tree.
>
> So lets begin merging with the minimal target core and the TCM_Loop as
> two separate commits. I think the target core may just fit under the
> reflector mail length limits, but if not, you can send it as multiple
> patches and I'll recombine them.
Well, could somebody eventually explain what are advantages of LIO over
SCST so you are choosing it?
LIO is obviously worse all technically (see
http://scst.sourceforge.net/comparison.html) as well as in the number of
users and size of the community. Current in-rush attempts to make LIO
_look_ not worse than SCST changed nothing in this area.
In the resent threads how many people voted for LIO? Nobody. How many
for SCST? Many. Moreover, has any real user of LIO participated in those
threads? None?
Doesn't that matter for you? Which code is the best doesn't matter for
Linux anymore?
Undercover games are going on?
Vlad
On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/17/2010 06:22 PM wrote:
> > OK, I think this has reached the stage where it's been polished enough
> > outside mainline to the point where we can complete any remaining todo
> > items in-tree.
> >
> > So lets begin merging with the minimal target core and the TCM_Loop as
> > two separate commits. I think the target core may just fit under the
> > reflector mail length limits, but if not, you can send it as multiple
> > patches and I'll recombine them.
>
> Well, could somebody eventually explain what are advantages of LIO over
> SCST so you are choosing it?
>
> LIO is obviously worse all technically (see
> http://scst.sourceforge.net/comparison.html) as well as in the number of
> users and size of the community. Current in-rush attempts to make LIO
> _look_ not worse than SCST changed nothing in this area.
To be honest, I don't really give a toss about niche feature
comparisons: both products have niche features the other doesn't. The
basic requirements in both products are solid. If the niche feature has
customer value, my estimation is that it can easily be added (to either
product).
> In the resent threads how many people voted for LIO? Nobody. How many
> for SCST? Many. Moreover, has any real user of LIO participated in those
> threads? None?
This isn't a democracy ... it's about choosing the most community
oriented code base so that it's easily maintainable and easy to add
feature requests and improvements as and when they come along. In the
past six months, LIO has made genuine efforts to clean up its act,
streamline its code and support the other community projects that would
need to go above and around it. You seem to have spent a lot of the
intervening time arguing with the sysfs maintainer about why you're
right and he's wrong.
James
> Doesn't that matter for you? Which code is the best doesn't matter for
> Linux anymore?
>
> Undercover games are going on?
>
> Vlad
James Bottomley, on 12/17/2010 07:21 PM wrote:
> On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote:
>> James Bottomley, on 12/17/2010 06:22 PM wrote:
>>> OK, I think this has reached the stage where it's been polished enough
>>> outside mainline to the point where we can complete any remaining todo
>>> items in-tree.
>>>
>>> So lets begin merging with the minimal target core and the TCM_Loop as
>>> two separate commits. I think the target core may just fit under the
>>> reflector mail length limits, but if not, you can send it as multiple
>>> patches and I'll recombine them.
>>
>> Well, could somebody eventually explain what are advantages of LIO over
>> SCST so you are choosing it?
>>
>> LIO is obviously worse all technically (see
>> http://scst.sourceforge.net/comparison.html) as well as in the number of
>> users and size of the community. Current in-rush attempts to make LIO
>> _look_ not worse than SCST changed nothing in this area.
>
> To be honest, I don't really give a toss about niche feature
> comparisons: both products have niche features the other doesn't. The
> basic requirements in both products are solid.
James, sorry, but your position is weak and absurd. In it maturity,
quality and features don't matter. Following this logic Linux kernel and
a student's home brewed OS kernel for his PhD work are equal. Obviously,
this is wrong. No doubts, that all what Linux kernel can do with the
same quality as it does can be added to the student's kernel sooner or
later, ... but after several decades of hard work of thousands of people.
Moreover, isn't Linux kernel and you as a maintainer supposed to choose
what is ALREADY the best, not what is promising to become better
somewhen in the future? Or not become.
> If the niche feature has
> customer value, my estimation is that it can easily be added (to either
> product).
If you eventually look on the technical comparison of SCST and LIO,
you'll see that SCST is far ahead in practically everywhere, in any
major area. Why not to compare yourself instead of blindly relying on
what NicholasB and his people are chea^H^H^H^Hsaying.
>> In the resent threads how many people voted for LIO? Nobody. How many
>> for SCST? Many. Moreover, has any real user of LIO participated in those
>> threads? None?
>
> This isn't a democracy ... it's about choosing the most community
> oriented code base so that it's easily maintainable and easy to add
> feature requests and improvements as and when they come along. In the
> past six months, LIO has made genuine efforts to clean up its act,
> streamline its code and support the other community projects that would
> need to go above and around it.
At first, can you recall any cases where community comments to SCST were
not addressed? All of them have been addressed and none ignored. NEVER.
Simply, LIO is very much premature code comparing to SCST. It is very
easy to find in it simple issues to comment, hence you see the big value
of comments.
In contrast, SCST has been maturing for many years (since 2004). It's
polished to high finish, so you can't so easily find out something to
improve in it. The feature requests and improvements in LIO you are
referring simply already in SCST.
Also, doesn't the size of the community reflects how community oriented
project is?
So far in the kernel community we see that, basically, the only person,
Christoph Hellwig, has taken responsibility to judge and he is pushing
LIO. Christoph is a very authoritative person, so many people are just
following his direction not dare to object. Nobody wants to go against
Christoph Hellwig. At max, people sending me private support e-mails
(thanks!) writing that SCST is great and obviously receives very unfair
treatment from the kernel maintainers.
But Christoph is a biased person. Several years ago he preferred
blessing STGT creation instead of already well existing at that moment
SCST. Now we know that was a wrong move and SCST was the right way to go.
Are we going to repeat that mistake again?
> You seem to have spent a lot of the
> intervening time arguing with the sysfs maintainer about why you're
> right and he's wrong.
Well, we are making the best designed and implemented code, right?
Aren't arguments part of this process?
Anyway, we almost finished a patch with new SCST sysfs interface, which
should satisfy Greg KH requirements. Bart several days ago sent proposed
new layout and Greg didn't object to it. We will send this patch in
several days.
Vlad
On Fri, 2010-12-17 at 22:47 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/17/2010 07:21 PM wrote:
> > On Fri, 2010-12-17 at 19:01 +0300, Vladislav Bolkhovitin wrote:
> >> James Bottomley, on 12/17/2010 06:22 PM wrote:
> >>> OK, I think this has reached the stage where it's been polished enough
> >>> outside mainline to the point where we can complete any remaining todo
> >>> items in-tree.
> >>>
> >>> So lets begin merging with the minimal target core and the TCM_Loop as
> >>> two separate commits. I think the target core may just fit under the
> >>> reflector mail length limits, but if not, you can send it as multiple
> >>> patches and I'll recombine them.
> >>
> >> Well, could somebody eventually explain what are advantages of LIO over
> >> SCST so you are choosing it?
> >>
> >> LIO is obviously worse all technically (see
> >> http://scst.sourceforge.net/comparison.html) as well as in the number of
> >> users and size of the community. Current in-rush attempts to make LIO
> >> _look_ not worse than SCST changed nothing in this area.
> >
> > To be honest, I don't really give a toss about niche feature
> > comparisons: both products have niche features the other doesn't. The
> > basic requirements in both products are solid.
>
> James, sorry, but your position is weak and absurd. In it maturity,
> quality and features don't matter.
I didn't say maturity and quality, I said niche features. Apparently
it's subjective, because both LIO and SCST think their own niche
features are essential and the other's are irrelevant.
> Following this logic Linux kernel and
> a student's home brewed OS kernel for his PhD work are equal.
So linux did begin as a student's home brewed OS kernel ...
> Obviously,
> this is wrong. No doubts, that all what Linux kernel can do with the
> same quality as it does can be added to the student's kernel sooner or
> later, ... but after several decades of hard work of thousands of people.
Precisely. Or said a different way: as long as you choose the most
community oriented of competing offerings, the community will fill any
perceived gaps. Conversely, you can destroy a project simply by
alienating the community. That's why community is more important than
feature set.
> Moreover, isn't Linux kernel and you as a maintainer supposed to choose
> what is ALREADY the best, not what is promising to become better
> somewhen in the future? Or not become.
No, see above. Many technically very competent potential additions to
linux have failed because of maintainer problems.
> > If the niche feature has
> > customer value, my estimation is that it can easily be added (to either
> > product).
>
> If you eventually look on the technical comparison of SCST and LIO,
> you'll see that SCST is far ahead in practically everywhere, in any
> major area. Why not to compare yourself instead of blindly relying on
> what NicholasB and his people are chea^H^H^H^Hsaying.
>
> >> In the resent threads how many people voted for LIO? Nobody. How many
> >> for SCST? Many. Moreover, has any real user of LIO participated in those
> >> threads? None?
> >
> > This isn't a democracy ... it's about choosing the most community
> > oriented code base so that it's easily maintainable and easy to add
> > feature requests and improvements as and when they come along. In the
> > past six months, LIO has made genuine efforts to clean up its act,
> > streamline its code and support the other community projects that would
> > need to go above and around it.
>
> At first, can you recall any cases where community comments to SCST were
> not addressed? All of them have been addressed and none ignored. NEVER.
>
> Simply, LIO is very much premature code comparing to SCST. It is very
> easy to find in it simple issues to comment, hence you see the big value
> of comments.
Look, I'm not interested in the backstabbing. *Both* projects have
fairly large user bases and businesses with revenue models built around
them, so I see that argument as a wash for both sides.
> In contrast, SCST has been maturing for many years (since 2004). It's
> polished to high finish, so you can't so easily find out something to
> improve in it. The feature requests and improvements in LIO you are
> referring simply already in SCST.
>
> Also, doesn't the size of the community reflects how community oriented
> project is?
>
> So far in the kernel community we see that, basically, the only person,
> Christoph Hellwig, has taken responsibility to judge and he is pushing
> LIO. Christoph is a very authoritative person, so many people are just
> following his direction not dare to object. Nobody wants to go against
> Christoph Hellwig. At max, people sending me private support e-mails
> (thanks!) writing that SCST is great and obviously receives very unfair
> treatment from the kernel maintainers.
>
> But Christoph is a biased person. Several years ago he preferred
> blessing STGT creation instead of already well existing at that moment
> SCST. Now we know that was a wrong move and SCST was the right way to go.
>
> Are we going to repeat that mistake again?
I don't think it was a mistake. STGT gave us the userspace modifiability
that neither LIO nor STGT offered at the time.
James
> > You seem to have spent a lot of the
> > intervening time arguing with the sysfs maintainer about why you're
> > right and he's wrong.
>
> Well, we are making the best designed and implemented code, right?
> Aren't arguments part of this process?
>
> Anyway, we almost finished a patch with new SCST sysfs interface, which
> should satisfy Greg KH requirements. Bart several days ago sent proposed
> new layout and Greg didn't object to it. We will send this patch in
> several days.
>
> Vlad
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
James Bottomley, on 12/17/2010 11:27 PM wrote:
>> James, sorry, but your position is weak and absurd. In it maturity,
>> quality and features don't matter.
>
> I didn't say maturity and quality, I said niche features. Apparently
> it's subjective, because both LIO and SCST think their own niche
> features are essential and the other's are irrelevant.
I also meant features. And those features are pretty much objective. See
the comparison page. As I wrote, I'm willing to add to it anything I
missed on the first request. Several month passed and there are no
requests from LIO. So, the page must be complete and accurate.
Although you can't ignore maturity and quality, especially considering
in which rush new features added in LIO in past months.
>From where do you know LIO and SCST are the same level of
maturity/quality? NicholasB told you so?
>> Following this logic Linux kernel and
>> a student's home brewed OS kernel for his PhD work are equal.
>
> So linux did begin as a student's home brewed OS kernel ...
Does it mean that we should throw away all those decades of work and
start again?
>> Obviously,
>> this is wrong. No doubts, that all what Linux kernel can do with the
>> same quality as it does can be added to the student's kernel sooner or
>> later, ... but after several decades of hard work of thousands of people.
>
> Precisely.
Yes, sure. After several decades of hard work of thousands of people.
Not now, when it's ready. We will believe and wait until it's done.
> Or said a different way: as long as you choose the most
> community oriented of competing offerings, the community will fill any
> perceived gaps. Conversely, you can destroy a project simply by
> alienating the community. That's why community is more important than
> feature set.
What in the SCST community doesn't satisfy you? It keeps growing, not
"alienating". SCST mailing list has a continual flow of new subscribers
as well as new patches. There are several hundreds messages a month in
it. Many people has been participating for many years.
What's wrong with it?
James, what exactly don't you like in the way how SCST maintained? Tell
us. We are following all the rules we know. But, definitely, you are not
happy with something.
>> At first, can you recall any cases where community comments to SCST were
>> not addressed? All of them have been addressed and none ignored. NEVER.
>>
>> Simply, LIO is very much premature code comparing to SCST. It is very
>> easy to find in it simple issues to comment, hence you see the big value
>> of comments.
>
> Look, I'm not interested in the backstabbing. *Both* projects have
> fairly large user bases and businesses with revenue models built around
> them, so I see that argument as a wash for both sides.
Me neither interested in backstabbing. But this is precisely what we are
seeing.
NicholasB pleased key people (don't know how he managed to do it,
although suspect), so now you are making absurd arguments trying to
prove that his second grade meat has the first class taste.
Opinions of ones who tried to eat it doesn't matter, because it isn't a
"democracy". From other side you don't want to try yourself, because
NicholasB said the test is perfect, so you believe in it.
Are we in an absurd Kafka novel?
>> Are we going to repeat that mistake again?
>
> I don't think it was a mistake. STGT gave us the userspace modifiability
> that neither LIO nor STGT offered at the time.
Following your logic, it shouldn't have mattered, right? Because it can
be added to SCST in the future. (LIO didn't even exist at that time.)
But SCST offered user space backend at about time STGT was merged. So,
it isn't too good argument.
What's interesting is that LIO even now doesn't allow it.
Moreover, accepting LIO is against your own rules you declared.
Particularly:
1. It doesn't have user space backend.
2. It exports some information via procfs, which was declared as a big
no-no.
So I keep wondering, why does LIO have so much privileged treatment, so
what was forbidden for SCST allowed for LIO?
Let's treat SCST equally and allow COMMUNITY, not particular BIASED
people to choose the best one!
In this regard it looks to be a good idea to freeze accepting both LIO
and SCST until the end of the next year and then choose one with the
biggest activity in the related mailing lists, not counting me and
NicholasB.
You want the best community, so let community choose!
Vlad
On Sat, 2010-12-18 at 00:35 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/17/2010 11:27 PM wrote:
> >> James, sorry, but your position is weak and absurd. In it maturity,
> >> quality and features don't matter.
> >
> > I didn't say maturity and quality, I said niche features. Apparently
> > it's subjective, because both LIO and SCST think their own niche
> > features are essential and the other's are irrelevant.
>
> I also meant features. And those features are pretty much objective. See
> the comparison page. As I wrote, I'm willing to add to it anything I
> missed on the first request. Several month passed and there are no
> requests from LIO. So, the page must be complete and accurate.
>
> Although you can't ignore maturity and quality, especially considering
> in which rush new features added in LIO in past months.
>
> From where do you know LIO and SCST are the same level of
> maturity/quality? NicholasB told you so?
Bored of this. I've explained half a dozen times my attitude here.
Both LIO and SCST are mature projects spanning most of the last decade.
> >> Following this logic Linux kernel and
> >> a student's home brewed OS kernel for his PhD work are equal.
> >
> > So linux did begin as a student's home brewed OS kernel ...
>
> Does it mean that we should throw away all those decades of work and
> start again?
>
> >> Obviously,
> >> this is wrong. No doubts, that all what Linux kernel can do with the
> >> same quality as it does can be added to the student's kernel sooner or
> >> later, ... but after several decades of hard work of thousands of people.
> >
> > Precisely.
>
> Yes, sure. After several decades of hard work of thousands of people.
> Not now, when it's ready. We will believe and wait until it's done.
>
> > Or said a different way: as long as you choose the most
> > community oriented of competing offerings, the community will fill any
> > perceived gaps. Conversely, you can destroy a project simply by
> > alienating the community. That's why community is more important than
> > feature set.
>
> What in the SCST community doesn't satisfy you? It keeps growing, not
> "alienating". SCST mailing list has a continual flow of new subscribers
> as well as new patches. There are several hundreds messages a month in
> it. Many people has been participating for many years.
>
> What's wrong with it?
Look, let me try to make it simple: It's not about the community you
bring to the table, it's about the community you have to join when you
become part of the linux kernel. The interactions in the wider
community are critical to the success of an open source project. You've
had the opportunity to interact with a couple of them: sysfs we've
covered elsewhere, but in the STGT case you basically said, here's our
interface, use it. LIO actually asked what they wanted and constructed
something to fit. Why are you amazed then when the STGT people seem to
prefer LIO?
You've also spent a lot of time doing ad hominem attacks on people who
you think disagree with you. Christoph can be abrasive and sometimes a
little tactless, but he's not often wrong on technical issues, and when
he is he's usually amenable to technical argument. He gave both LIO and
SCST pointers about improvements. LIO implemented enough that he felt
comfortable sending in fairly radical cleanup patches ... again, it's no
real surprise he prefers LIO to work with.
Basically, in the years we've been at this, you've failed to convince
any of the key people I rely on to help maintain SCSI to advocate for
SCST or even to send in patches for it ... they all seem to be either
neutral or leaning towards LIO.
You see conspiracy in this ... I just see LIO being accommodating to
their technical needs.
> James, what exactly don't you like in the way how SCST maintained? Tell
> us. We are following all the rules we know. But, definitely, you are not
> happy with something.
>
> >> At first, can you recall any cases where community comments to SCST were
> >> not addressed? All of them have been addressed and none ignored. NEVER.
> >>
> >> Simply, LIO is very much premature code comparing to SCST. It is very
> >> easy to find in it simple issues to comment, hence you see the big value
> >> of comments.
> >
> > Look, I'm not interested in the backstabbing. *Both* projects have
> > fairly large user bases and businesses with revenue models built around
> > them, so I see that argument as a wash for both sides.
>
> Me neither interested in backstabbing. But this is precisely what we are
> seeing.
>
> NicholasB pleased key people (don't know how he managed to do it,
> although suspect), so now you are making absurd arguments trying to
> prove that his second grade meat has the first class taste.
>
> Opinions of ones who tried to eat it doesn't matter, because it isn't a
> "democracy". From other side you don't want to try yourself, because
> NicholasB said the test is perfect, so you believe in it.
>
> Are we in an absurd Kafka novel?
Yes, we are ... but I don't think you appreciate whose.
> >> Are we going to repeat that mistake again?
> >
> > I don't think it was a mistake. STGT gave us the userspace modifiability
> > that neither LIO nor STGT offered at the time.
>
> Following your logic, it shouldn't have mattered, right? Because it can
> be added to SCST in the future. (LIO didn't even exist at that time.)
>
> But SCST offered user space backend at about time STGT was merged. So,
> it isn't too good argument.
>
> What's interesting is that LIO even now doesn't allow it.
>
> Moreover, accepting LIO is against your own rules you declared.
> Particularly:
>
> 1. It doesn't have user space backend.
Oh come on ... this one's been over the lists and Mike and Tomo have
actually approved of the LIO solution for them
> 2. It exports some information via procfs, which was declared as a big
> no-no.
I looked at the code fairly carefully and didn't find this ... where is
it?
> So I keep wondering, why does LIO have so much privileged treatment, so
> what was forbidden for SCST allowed for LIO?
>
> Let's treat SCST equally and allow COMMUNITY, not particular BIASED
> people to choose the best one!
>
> In this regard it looks to be a good idea to freeze accepting both LIO
> and SCST until the end of the next year and then choose one with the
> biggest activity in the related mailing lists, not counting me and
> NicholasB.
>
> You want the best community, so let community choose!
Essentially, I did ... it has.
James
On Sat, Dec 18, 2010 at 12:26 AM, James Bottomley
<[email protected]> wrote:
> On Sat, 2010-12-18 at 00:35 +0300, Vladislav Bolkhovitin wrote:
> > [ ... ]
> > 2. It exports some information via procfs, which was declared as a big
> > no-no.
>
> I looked at the code fairly carefully and didn't find this ... where is
> it?
Does this mean that you didn't have a look yet at this patch ?
[PATCH v2 02l/03] target: Add SCSI MIB statistics support
Bart.
On Fri, Dec 17, 2010 at 9:27 PM, James Bottomley
<[email protected]> wrote:
> [ ... ]
> Look, I'm not interested in the backstabbing. ?*Both* projects have
> fairly large user bases and businesses with revenue models built around
> them, so I see that argument as a wash for both sides.
References please. Since several years there is much more activity on
the SCST mailing list than on the LIO mailing list, what makes me
wonder about the size of the LIO user base.
And regarding revenue models: I'm not sure any of these projects is
currently generating enough revenue to even sustain a single person.
Bart.
James Bottomley, on 12/18/2010 02:26 AM wrote:
> Look, let me try to make it simple: It's not about the community you
> bring to the table, it's about the community you have to join when you
> become part of the linux kernel. The interactions in the wider
> community are critical to the success of an open source project. You've
> had the opportunity to interact with a couple of them: sysfs we've
> covered elsewhere, but in the STGT case you basically said, here's our
> interface, use it. LIO actually asked what they wanted and constructed
> something to fit. Why are you amazed then when the STGT people seem to
> prefer LIO?
>
> You've also spent a lot of time doing ad hominem attacks on people who
> you think disagree with you. Christoph can be abrasive and sometimes a
> little tactless, but he's not often wrong on technical issues, and when
> he is he's usually amenable to technical argument. He gave both LIO and
> SCST pointers about improvements. LIO implemented enough that he felt
> comfortable sending in fairly radical cleanup patches ... again, it's no
> real surprise he prefers LIO to work with.
>
> Basically, in the years we've been at this, you've failed to convince
> any of the key people I rely on to help maintain SCSI to advocate for
> SCST or even to send in patches for it ... they all seem to be either
> neutral or leaning towards LIO.
OK, then how those years looked from our side.
In the beginning decision to go on with STGT was done completely behind
my back. ChristophH and MikeC did review of SCST code, but from comments
I've seen and SCST patches Mike was preparing it was obvious for me that
Christoph and Mike not really understood all the tasks SCST is solving
and, hence why its code so complicated. Particularly, the goal of all
the code to provide 1:many pass-through was not understood. But nobody
asked me to explain. The need in the 1:many pass-through code was
understood only much later after
http://thread.gmane.org/gmane.linux.scsi/31288. The decision to go ahead
with STGT was just taken. I knew about it only after I accidentally saw
some related discussion
http://thread.gmane.org/gmane.linux.iscsi.iscsi-target.devel/1996/focus=2022.
When I tried to explain that it's wrong, I wasn't heard.
You were attracted by the STGT idea by 2 points:
1. Minimal in-kernel maintenance effort.
2. Believe that mmap'ing user space pages can provide similar
performance as fully in-kernel approach.
I disagreed with both. I wasn't heard. But it turned out that at least
one person in the Linux kernel community agreed with me: Linus Torvalds.
See http://lkml.org/lkml/2007/4/24/364 for (1) and
http://lkml.org/lkml/2008/2/4/253 for (2).
Then I kept sending SCST patches and they were ignored by you and "the
key people". We were told that STGT is "good enough" despite of all the
obvious problems it has.
Then suddenly NicholasB appeared with his LIO and suddenly what I was
writing for years was acknowledged correct: STGT isn't good enough and
must be replaced by the fully in-kernel approach.
So, it turned out that I was right all those years and convinced all the
key people at once by the NicholasB hands?
So, writing that I failed to convince any of the key people isn't quite
correct.
It looks like those years I've been staying a step ahead and wasn't
heard. What were the reasons for it? My limited English, which isn't my
native language, so I can't use it similarly correctly and clearly as
native Americans can? I'm working hard to improve it and, hopefully,
progress is noticeable. Similarly, I'm willing to improve in any other
area. Just tell me what should be done?
>> Are we in an absurd Kafka novel?
>
> Yes, we are ... but I don't think you appreciate whose.
Definitely not. I don't like living in a place when rules are just
declarations and interpreted any way as key people want, even opposite
to what the rules supposed to mean.
>> Moreover, accepting LIO is against your own rules you declared.
>> Particularly:
>>
>> 1. It doesn't have user space backend.
>
> Oh come on ... this one's been over the lists and Mike and Tomo have
> actually approved of the LIO solution for them
They approved the direction to move on, not the code implementing it.
There's no such code and has never been, while you declared that such
code is REQUIRED for an STGT drop in replacement.
>> 2. It exports some information via procfs, which was declared as a big
>> no-no.
>
> I looked at the code fairly carefully and didn't find this ... where is
> it?
http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob_plain;f=drivers/target/target_core_mib.c;hb=10eae38203a01a26fca3b2097f13e48a0ba2d38f
>> So I keep wondering, why does LIO have so much privileged treatment, so
>> what was forbidden for SCST allowed for LIO?
>>
>> Let's treat SCST equally and allow COMMUNITY, not particular BIASED
>> people to choose the best one!
>>
>> In this regard it looks to be a good idea to freeze accepting both LIO
>> and SCST until the end of the next year and then choose one with the
>> biggest activity in the related mailing lists, not counting me and
>> NicholasB.
>>
>> You want the best community, so let community choose!
>
> Essentially, I did ... it has.
Which community do you mean? Few selected people on the invitation-only
storage summit?
Sorry, James, but all your arguments so far come to a single one: "I
like Nicholas Bellinger and the way he makes deals, so I want him here.
I'll do my best to push him in. I want it so much, so I'm willing to
alter any rules to suit him, even declare black white, if necessary.".
I'm not sure even in the quality of review of the NicholasB's code,
since somehow such big thing as the proc interface managed to slipped it.
Apparently, such preferred treatment leaves a lot of space for
conspiracy theories.
People believe that Linux kernel is a sane place free from dirty
undercover politics, where the best code wins, so it will be a huge
disappointment for everyone if this believe turns out be wrong.
Vlad
On Sat, 2010-12-18 at 18:16 +0300, Vladislav Bolkhovitin wrote:
> James Bottomley, on 12/18/2010 02:26 AM wrote:
> > Look, let me try to make it simple: It's not about the community you
> > bring to the table, it's about the community you have to join when you
> > become part of the linux kernel. The interactions in the wider
> > community are critical to the success of an open source project. You've
> > had the opportunity to interact with a couple of them: sysfs we've
> > covered elsewhere, but in the STGT case you basically said, here's our
> > interface, use it. LIO actually asked what they wanted and constructed
> > something to fit. Why are you amazed then when the STGT people seem to
> > prefer LIO?
> >
> > You've also spent a lot of time doing ad hominem attacks on people who
> > you think disagree with you. Christoph can be abrasive and sometimes a
> > little tactless, but he's not often wrong on technical issues, and when
> > he is he's usually amenable to technical argument. He gave both LIO and
> > SCST pointers about improvements. LIO implemented enough that he felt
> > comfortable sending in fairly radical cleanup patches ... again, it's no
> > real surprise he prefers LIO to work with.
> >
> > Basically, in the years we've been at this, you've failed to convince
> > any of the key people I rely on to help maintain SCSI to advocate for
> > SCST or even to send in patches for it ... they all seem to be either
> > neutral or leaning towards LIO.
>
> OK, then how those years looked from our side.
>
> In the beginning decision to go on with STGT was done completely behind
> my back. ChristophH and MikeC did review of SCST code, but from comments
> I've seen and SCST patches Mike was preparing it was obvious for me that
> Christoph and Mike not really understood all the tasks SCST is solving
> and, hence why its code so complicated. Particularly, the goal of all
> the code to provide 1:many pass-through was not understood. But nobody
> asked me to explain. The need in the 1:many pass-through code was
> understood only much later after
> http://thread.gmane.org/gmane.linux.scsi/31288. The decision to go ahead
> with STGT was just taken. I knew about it only after I accidentally saw
> some related discussion
> http://thread.gmane.org/gmane.linux.iscsi.iscsi-target.devel/1996/focus=2022.
> When I tried to explain that it's wrong, I wasn't heard.
>
> You were attracted by the STGT idea by 2 points:
>
> 1. Minimal in-kernel maintenance effort.
>
> 2. Believe that mmap'ing user space pages can provide similar
> performance as fully in-kernel approach.
>
> I disagreed with both. I wasn't heard. But it turned out that at least
> one person in the Linux kernel community agreed with me: Linus Torvalds.
> See http://lkml.org/lkml/2007/4/24/364 for (1) and
> http://lkml.org/lkml/2008/2/4/253 for (2).
>
> Then I kept sending SCST patches and they were ignored by you and "the
> key people". We were told that STGT is "good enough" despite of all the
> obvious problems it has.
This is a slightly prismatic view of history. Firstly, LIO had wanted
into the kernel from way back in the PyX days and secondly, both code
bases (LIO and STGT) were impenetrably dense, had unacceptable /proc
interfaces plus a whole host of other nasties. The decision to choose a
smaller (by an order of magnitutde) and more flexible implementation
that was in accord with all of the basic Linux necessities was a pretty
obvious one.
>From a performance point of view, (which is what the thread was about),
I'm OK with the assertion that there is a point where kernel/user
transitions dominate (by your own figures somewhere above 1GbE) which is
about the only reason I'm willing to consider an in-kernel solution.
> Then suddenly NicholasB appeared with his LIO and suddenly what I was
> writing for years was acknowledged correct: STGT isn't good enough and
> must be replaced by the fully in-kernel approach.
I'm not sure where you read that. I said, for performance, adding
in-kernel components to STGT would be OK ... keeping the user space
flexibility is still equally (or more) important.
> So, it turned out that I was right all those years and convinced all the
> key people at once by the NicholasB hands?
>
> So, writing that I failed to convince any of the key people isn't quite
> correct.
>
> It looks like those years I've been staying a step ahead and wasn't
> heard. What were the reasons for it? My limited English, which isn't my
> native language, so I can't use it similarly correctly and clearly as
> native Americans can? I'm working hard to improve it and, hopefully,
> progress is noticeable. Similarly, I'm willing to improve in any other
> area. Just tell me what should be done?
Well, you and Nick have each kept repeating that about your respective
products ... it's the Bellman gambit. From the performance point of
view, you're both about equal ... the Niche Features piece I've covered
elsewhere.
Fewer than half of the key players in the storage area are native
english speakers.
James
On Fri, Dec 17, 2010 at 3:27 PM, James Bottomley
<[email protected]> wrote:
>
> > ?Obviously,
> > this is wrong. No doubts, that all what Linux kernel can do with the
> > same quality as it does can be added to the student's kernel sooner or
> > later, ... but after several decades of hard work of thousands of people.
>
> Precisely. ?Or said a different way: as long as you choose the most
> community oriented of competing offerings, the community will fill any
> perceived gaps. ?Conversely, you can destroy a project simply by
> alienating the community. ?That's why community is more important than
> feature set.
>
Your definition of community encompasses just the lead developers and
not average developers. This ain't right. If community is more
important then SCST should at least be heard before leaning towards
LIO.
It was decided a year ago to merge LIO without sending any emails on
LKML or linux-scsi. I've mentioned this repeatedly and you've been
conveniently ignoring this fact.
> > Moreover, isn't Linux kernel and you as a maintainer supposed to choose
> > what is ALREADY the best, not what is promising to become better
> > somewhen in the future? Or not become.
>
> No, see above. ?Many technically very competent potential additions to
> linux have failed because of maintainer problems.
>
And what maintainer problems is SCST posing to the linux community??
You clearly distorted the facts during linux-con 2010 when I asked you
about SCST. You said 'SCST cannot be integrated because Vlad is not
comfortable relinquishing control of SCST'. It's GPL'd code. What
control were you talking about?
> > > This isn't a democracy ... it's about choosing the most community
> > > oriented code base so that it's easily maintainable and easy to add
> > > feature requests and improvements as and when they come along. ?In the
> > > past six months, LIO has made genuine efforts to clean up its act,
> > > streamline its code and support the other community projects that would
> > > need to go above and around it.
> >
Ok, so our request was simple. Let's have a review at the architecture
and block level rather than sending patch-emails.
Others seem to agree at this approach so why can't you take it as an
action item please? This way we can stop this email drama, no?
> > > You seem to have spent a lot of the
> > > intervening time arguing with the sysfs maintainer about why you're
> > > right and he's wrong.
> >
Just for argument sake, if zero time was spent on discussing the sysfs
plane and if a patch was cut the next day you would have merged SCST?
Ok, so Bart sent the patch. Now what?
Chetan
On Fri, Dec 17, 2010 at 4:35 PM, Vladislav Bolkhovitin <[email protected]> wrote:
>
> In this regard it looks to be a good idea to freeze accepting both LIO
> and SCST until the end of the next year and then choose one with the
> biggest activity in the related mailing lists, not counting me and
> NicholasB.
>
Why wait till the end of the next year? What I proposed earlier was
'to review at the architecture level'. If folks don't agree to it then
this email drama will never
stop. Once the review starts we can decide on a common baseline to
benchmark both the stacks. I'm more than willing to test/benchmark
ESX(front-end)/SCST/LIO(back-end) combo. I'm sure there will be others
who would be willing to spend some of their time for this cause to
validate claims made by both the communities. We can then publish all
the results so that others can reproduce them.
> You want the best community, so let community choose!
>
Sure, and then we will let community choose what's best for them. And
if that means picking the best from both the worlds and coming up w/ a
unified stack then that's great!
> Vlad
> --
Chetan
James Bottomley, on 12/18/2010 07:41 PM wrote:
> This is a slightly prismatic view of history. Firstly, LIO had wanted
> into the kernel from way back in the PyX days and secondly, both code
> bases (LIO and STGT) were impenetrably dense, had unacceptable /proc
> interfaces plus a whole host of other nasties. The decision to choose a
> smaller (by an order of magnitutde) and more flexible implementation
> that was in accord with all of the basic Linux necessities was a pretty
> obvious one.
Sorry, James, but your view is even more prismatic.
On the PyX days LIO didn't even exist. Those days it was an iSCSI target
and only iSCSI target, like IET, without any sign of be generic and
support other transports.
Regarding "dense" SCST code. This is exactly what I meant writing that
for me apparent that reviewers were not fully understanding the tasks
SCST was solving. If you don't understand tasks to solve, code solving
them would be terribly hard to read, correct? For instance, if a person
believes that for pass-through the only needed is to pass incoming
requests to backend SCSI hardware and responses from it to the sender,
for him code emulating multi-nexus functionality by intercepting
requests and responses would look like a huge overkill and impenetrably
dense to read.
Regarding unacceptable /proc interface. LIO still has it, but it doesn't
prevent you accepting it. Several days passed since we pointed on it,
but you have not requested to remove it.
Regarding the "host of other nasties". Nobody ever reported them. Maybe,
they didn't exist?
>> Then suddenly NicholasB appeared with his LIO and suddenly what I was
>> writing for years was acknowledged correct: STGT isn't good enough and
>> must be replaced by the fully in-kernel approach.
>
> I'm not sure where you read that. I said, for performance, adding
> in-kernel components to STGT would be OK ... keeping the user space
> flexibility is still equally (or more) important.
Well, the fact is that LIO and SCST have fundamentally the same
architecture (LIO is just a worsened SCST several years back), so
accepting LIO now you are confirming that SCST should have been accepted
instead of STGT years ago.
Let's summarize what we have for people not fully following our discussion.
1. Linux kernel is believed to be a place gathering the best code and
the best talents. New people believe that if they do the best writing
the best code, it will be appreciated.
2. Choosing target mode subsystem you declare that neither code quality,
nor advance of implementation, nor features set, nor users base, nor
community size are important for you, hence considered. You believe that
everything can be implemented somewhen in the future. What to do users
while what they need not implemented yet is outside of scope of your
consideration.
3. The only thing matters for you is personality of who submitted the
code. Namely, you like Nicholas A. Bellinger and have chosen him. Hence,
you have chosen LIO. (BTW, rumors suggest you have long standing close
relationship with NicholasB since the PyX times at least.)
4. What was strong requirements few years ago against SCST (no /proc
interface and must have user space backend) for LIO not required. You
can accept it without those requirements satisfied.
5. To make your decision legitimate on the closed invitation-only
storage summit, where there were only people you control and nobody from
the SCST community, those people voted for LIO.
No other result could be expected, because, for instance, Mike Christie
clearly specified in https://bugzilla.redhat.com/show_bug.cgi?id=592147
that he will choose whatever you choose.
Another key person you are referring to, FUJITA Tomonori, also many
times has written that he will do only what you approve to do.
Who else voted for LIO?
6. Now you are referring on that as it was not your decision. Your
community decided it for you.
James, doesn't it smell fishy?
All those instead of an OPEN and FAIR comparison of all aspects of
subsystems to choose the best one.
Sorry, but the next logical step would be merge into the kernel for sale?
Vlad
P.S. Regarding personality of Nicholas A. Bellinger and methods he is
considering acceptable. Page
http://www.linux-iscsi.org/index.php/Main_Page is the most crying
deliberate lie about SCST I've ever seen.
Particularly statement: "SCST [...] is an improved version of IET. It
has been developed by a team in Russia and has made Linux usable as an
IP storage operating system."
At first, SCST has no relation to IET. At all. NicholasB has been
following SCST development sufficiently long to know that IET-derived
iSCSI-SCST target driver was added relatively recently when SCST already
well working with other target drivers (qla2x00t and ib_srpt, for instance).
Second, I'm the only person from Russia in the SCST community. This is
obvious from scst-devel@ mailing list on which NicholasB has been
subscribed for many years. Moreover, for what is mentioning nationality
in this context at all? Attempt to negatively affect SCST by exploiting
not too good image Russia has at the moment in some Western countries?
Third, SCST "makes Linux usable" as ANY SCSI-speaking storage, including
Fibre Channel, SAS, etc. NicholasB knows it very well.
It's also very nice to see on that page SCST declared "legacy" :).
Regarding the comparison page, it has always been inaccurate about SCST
and always in the direction to discredit it. Everybody are people and
everybody make mistakes. But if attempts to point out on them ignored,
mistakes become deliberate cheating. I several times e-mailed NicholasB
explaining those mistakes, but all the times my messages were ignored. I
also was blocked sending messages to the LIO mailing list. (Correct
values for the comparison page you can find on
http://scst.sourceforge.net/comparison.html page).
Such cheating attempts to discredit SCST we have been constantly feeling
since we first time heard NicholasB's name.
Thus, James apparently thinks that the kernel community is too purified,
so it will be good to add to it some sense of undercover intrigues to
make it closer to real life ;)
chetan loke, on 12/18/2010 10:13 PM wrote:
> On Fri, Dec 17, 2010 at 4:35 PM, Vladislav Bolkhovitin <[email protected]> wrote:
>>
>> In this regard it looks to be a good idea to freeze accepting both LIO
>> and SCST until the end of the next year and then choose one with the
>> biggest activity in the related mailing lists, not counting me and
>> NicholasB.
>
> Why wait till the end of the next year? What I proposed earlier was
> 'to review at the architecture level'. If folks don't agree to it then
> this email drama will never
> stop. Once the review starts we can decide on a common baseline to
> benchmark both the stacks. I'm more than willing to test/benchmark
> ESX(front-end)/SCST/LIO(back-end) combo. I'm sure there will be others
> who would be willing to spend some of their time for this cause to
> validate claims made by both the communities. We can then publish all
> the results so that others can reproduce them.
This will be exactly what we need: an open and fair comparison. But the
problem is that James doesn't want any comparisons. He doesn't consider
them important. Only personality of the code submitter is important for
James.
Vlad