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
--
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
