[lkml]   [2005]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] zfcp: add rports to enable scsi_add_device to work again
On 27.08.2005 19:38 James Bottomley <> wrote:

> > this patch fixes a severe problem with 2.6.13-rc7.
> >
> > Due to recent SCSI changes it is not possible to add any
> > LUNs to the zfcp device driver anymore. With registration
> > of remote ports this is fixed.
> >
> > Please integrate the patch in the 2.6.13 kernel or if it
> > is already too late for this release then please integrate it
> > in
> >
> > Thanks a lot.

> Well, OK, but your usage isn't quite optimal. The fibre channel
> transport class retains a list of ports per host, so your maintenance
> an identical list in zfcp_adapter duplicates this.

I know what you mean. It would be better to store all "private" zfcp
data at dd_data in fc_rport. Unfortunately it won't fit to zfcp's
current behaviour. The rport depends on a specific host_id. Even the
name of the rport in sys/class/fc_remote_port inherits this id. This
means if the host is deregistered and registered again the old rport
structure is useless because new host_ids are assigned. Or do I miss
something here?

The zfcp_port structure is thought to be persistent if once configured
by the user, i.e. even if the host is deregistered and registered
again the port structure is kept.

I am not sure at the moment how this can be solved with the current
fc_transport. I think it would have been better to use the WWPN of an
rport as the name in sys/class/fc_remote_port. This would be a start
to keep rport structures independent of the host_id. (Why should the
transport depend on OS assigned ids anyway? The transport has already
unique identifiers like WWPNs.)

> However, we can put this in for now and worry about removing all of
> fc transport class duplication from zfcp later.

> James

In any case attributes provided by an rport should be removed from the
zfcp_port structure. This is what I will do next.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-29 10:08    [W:0.047 / U:2.896 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site