I started to work on SMP pass through via bsg as a non-SCSI command
experimentation. I asked Doug to try the patch but it seems to take
some time to make Doug's hardware work with the mainline aic94xxx
driver. Meanwhile, I'd like to discuss some issues.
- user/kernel interface
How should a user-space tool (like Doug's smp_utils) send a request
and get the response via bsg?
-- each SAS object (host, device, expander, etc) has the own bsg device
A user-space tool opens a bsg device for a sas object that it wants to
send a request to.
-- one bsg device handles multiple SAS objects
Some options: one bsg device in the whole system; one bsg device per
SAS driver; one bsg device per SAS host; etc.
With this approach, we need to invent a header incluing routing
information.
My hacky patch creates one bsg device per SAS host and invents:
struct smp_passthrough_hdr {
__u64 sas_address;
__u8 phy_identifier;
};
a user-space tool sends this header instead of scb via bsg and put a
SMP request at dout_xfer and a buffer response at din_xfer (note that
now I do bidi transfer in a hacky way).
- SAS implementation details
As I said, the patch is too hacky. I just tried to implement a
smp_portal alternative by using bsg.
The patch adds a hook into sas transport class. sas_host_setup calls
bsg_register_queue. Then, the request_fn calls smp_execute_task to
send a smp request and get the response. It doesn't look good to link
the sas transport class with libsas. In addition, the mpt driver
handles smp request/response in a very different way.
Any suggestion to bind SMP pass through via bsg to aic94xx and mpt
cleanly?
-
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
