[dm-devel] Re: 1st of 2 patches for dm_emc.c and dm-multipath hardware handler interface

[Mike Christie]

Mike Christie wrote:
> Edward Goggin wrote:
>> +
>> +	rq->buffer = rq->data = h->buffer;
>> +	rq->data_len = len;
>> +	rq->bio = rq->biotail = NULL;
>>  
> 
> I think I only suggested that you use the block layer map functions in
> the previous review. Now I will say, use them and fix the core code to
> not allocate memory or use a mempool since it will also fix the path
> testers at the same time :) The reason is that the scsi layer is trying
> to make every thing run with scatterlists. In 2.6.18, every place is
> converted (they should be at least), so you should not be adding another
> place where we send down a data buffer like this.
> 

And if we are going to continue to do some scsi processing in dm I
already did some helpers you could base yourself off of here

http://www.cs.wisc.edu/~michaelc/block/dm/v4/


In dm_scsi_end_rq, you could handle errors like transient transport
failures for all hw handlers at one tine.

http://www.cs.wisc.edu/~michaelc/block/dm/v4/02-dm-scsi-helpers.patch

And in fact a lot of your patch has already been done with this patch

http://www.cs.wisc.edu/~michaelc/block/dm/v4/03-emc.patch a year ago.

We really need to change how dm-multipath development works IMHO.
Alasdair is just too overworked. It is not fair to him to have so much
work piled on top of him and not fair to the community to have problems
like this sit around for so long.

The basics of the hw handler framework were done when I did my pg group
callouts that improved on Joe's idea to put everything in the path
selectors. It took a year after that to get hw handlers, which made some
of the same architectural mistakes as well as odd coding choices that I
made, in the kernel. And now for another year we have been sitting on
these type of bugs and problems where we need some of the hw handler
functionality in the scsi layer as well as dm layer.

With Alasdair having to maintain every driver that dm handles and those
drivers increasing in complexity the work load is too large for one
person and this makes coordination with other subsystems impossible.
This is a large problem, when for something like dm-multipath it needs
help from the block layer, and low levels like scsi.

We really need a system like in the scsi layer where there are driver
maintainers and then one core maintainer of the subsystem. The core
maintainer has final (well ok community has final say I guess) say but
trusts the low level driver maintainers to some extent. The low level
driver maintainers still have to post patches for review to the
community and maintainer but the core maintainer does not have to do a
line by line review of the dm target module and learn all the lower
level details of the sub-subsytem/lld/dm target module/transport/spec
unless it affects dm core or it is a suspicious patch.

Just my 2 cents.