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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Christie wrote:
> Edward Goggin wrote:
>> On Friday, September 08, 2006 2:00 PM, Mike Christie wrote
>>> 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/
>> I was first trying to submit these changes to the upstream code
>> (I chose 2.6.18-rc4) since I this is what I thought you had
>> suggested that I do when we talked about it briefly at the dm bof
>> session at OLS.
>>
>> Should I not be taking this tack?
>>
> 
> I have no idea what Alasdair wants exactly and I have no idea when we
> are going to do anything.
> 
> I thought you were going to all the trouble of redoing your patches and
> fixing them up for review comments because you and alasdair switched and
> were staying with the hw handlers completely in dm-multpath route, or I
> thought the reason you were going to all this trouble to update your
> code and go through the review process was because for RHEL 5, we were
> staying with the hw handlers completely in dm-multipath route.
> 

Oh yeah, the comment about making the bios allocated from a per queue
pool like the requests and changing the allocation flags that are used
in those paths should be handled no matter where we put things and what
distro we are talking about. That should be a separate patch that goes
through the block layer maintainer though, since it fixes issues in the
block sg and scsi layer we well as dm.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux