Re: [PATCH 0/2] FC pass through support via bsg interface

[James Smart <James.Smart@Emulex.Com>]

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