Mike Christie wrote:
- In general without knowing how hardware is really going to hook into
the lib it is hard to say how the rearch is going :) If we cannot
move more of the fc_remote_port to the rport (or if we just do not
want to move it all there because other drivers like lpfc and qla2xxx
will never use it) then we might want to rename the fc_remote_port
to avoid confusion with the rport and make it clear that the libfc
remote
port is only needed for libfc operations.
We'd like to reduce fc_remote_port to nothing and only use fc_rport.
We're still not sure we can completely achieve this without either
having some private data or adding fields to the fc_rport.
On a related note, are there going to be values that we need to export
in sysfs that are specific to fcoe? For remote port values are we going
to export them on the fc_rport (is the fc_rport for anything and
everything related to FC) or some new struct?
If it is a new struct, what if a driver does not use any
fc_transport_template callouts and does not hook into libfc?
Should the fc_transport_template be merged with the
fc_function_template?
The function callouts to do things lke abort IO or cleanup commands
look
similar. But in general should the fc_function_template be common for
all
fc drivers and should the fc_transport_template be just for the ones
that
are
going to hook into the libfc? If the latter maybe we want to rename
this to
make the visibility clear.
So something like libfc_transport_template?
That makes it clear, but I do not know if it is a good name. It sounds
ugly like something I would name it (I am not good at naming as you can
tell from some of the iscsi function names). All I know is that the
original is not so clear :)
Oh yeah, sorry I did not give a good answer to this. I was thinking if
we are thowing everything (fcoe specific attrs) on the scsi_transport_fc
fc_rport or fc_host then we might as well throw the callouts on
fc_function_template.
--
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
