James Smart wrote:
>
>
> Sven Schuetz wrote:
>> Hi Seokmann,
>>
>> first of all, thanks for your efforts so far, good work!
>
> I second this!
>
>> Regarding the following statement from James and your question to it:
>>
>> Seokmann Ju wrote:
>>> On Sep 12, 2008, at 9:49 AM, James Smart wrote:
>>>
>>>> Seokmann,
>>>>
>>>> There are number of fundamental issues with this patch that need to be
>>>> corrected. I'll be at plumbers conference next week, and will be able
>>>> to work through this. Please look me up if you will be there.
>>>> Otherwise, I'll just post a revised patch.
>>>>
>>>> Here are the issues as I see them:
>>>>
>>
>> <snip>
>>
>>>> - We really should add support, for the initial merge, to talk to an
>>>> address that doesn't exist via an rport (think fabric service).
>>>> This means adding some request types to the fc_host too.
>>> This one too, please.
>>>> -- james s
>>>>
>>
>> <snip>
>>
>>
>> From what I have seen, that's still missing from your latest
>> submission. What
>> James means by that (James, correct me when I am wrong) is that at the
>> moment we
>> only have devices for rports under /dev.
>> That's good for ELS requests, but for CT requests that are not
>> directed to
>> individual rports but to some well known address that's not
>> appropriate. I think
>> there might also be situations when there are no rports available and
>> yet you
>> still want to issue a CT request. In my opinion we would need devices
>> for the
>> fc_hosts under /dev as well. I have not looked at it in detail yet but it
>> probably means to add a device struct to the fc_host_attrs struct
>> similar as it
>> is done for rports and register them with the block layer as well.
>> Maybe it's
>> feasible to have a dedicated ELS and CT handler in the transport layer
>> instead
>> of a generic service handler than (CT requets come in via
>> /dev/fc_hostx and are
>> handled by some fc_ct_service function and ELS requests come in via
>> /dev/rportxxx and are handled by sme fc_els_service function), but that's
>> something that needs to be looked at.
>> If you already have some ideas on how to do that, please let me know.
>> I might
>> start some experiments as well if I find the time.
>>
>> Sven
>
> I've started this work, and am merging it with Seokman's patches. The
> recent respins have reset it. This work is also good for validating the
> request/response formats, as it extends the requests to target
> transport handlers that do more than ELS/CT. So it's a good reference to
> ensure things are partitioned correctly.
>
> Seokman: I applied your last "revised III" patches - and the qla (2nd)
> patch failed miserably against scsi-misc-2.6. What were the patches cut
> against ?
>
> -- james s
>
Hi James, Hi Seokmann,
I have been able to get CT and ELS requests working with our zfcp device driver
with your patch, great!
At the moment there are only two issues left:
- the one I described above (not having an adapter device for CT requests).
James, if you need any help or want me to test your patch, I'd happily do so.
- in our driver we need to distinguish the incoming CT requests so that we can
open the according WKA port and send the request to it. To do this at the
moment, I have to read the first few bytes of the CT frame from the
scatter-gather-list to see what generic service is targeted (byte 5 in the frame
specifies the service). That's bit awkward. What about extending the request
structures Seokmann defined in scsi_transport_fc.h in a manner like:
struct fc_service_request {
u8 request_type;
u8 timeout;
u8 reserved0;
u8 reserved1;
};
becomes:
struct fc_service_request {
u8 request_type;
u8 request_subtype;
u8 timeout;
u8 reserved1;
};
Then we could define the type of generic service (directory service, alias
service etc) in the subtype field, without having to look at the
scatter-gather-list in the driver.
Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
