Nicholas A. Bellinger wrote:
On Fri, 2005-04-29 at 14:20 -0700, Mike Christie wrote:
The reason all the settings are stuck on the session was becuase we couldn't
come to an agreement on the layout. We wanted to do something like this:
/sys/class/iscsi_session/iscsi_connection
or even
/sys/class/iscsi_session
/sys/class/iscsi_connection
I am still thinking on this one. First and foremost I think that we
need to get move towards a single class for iSCSI Initiators instead of
what is currently registered (/sys/class/iscsi_transport
and /sys/class/iscsi_host). Let me keep working on this some more and I
will draft up a prosposal in the near future. Any futher input is
welcomed. :-)
get everyone to agree (or force them) on how to set the initiarname and alias
and the iscsi_host can be chopped. the iscsi_host is only there becuase sfnet
used a /etc file and I think you can set the initiatorname on some HW cards
from a BIOS/OF prompt (or you will not have control over it) so if they ever
end up on the same box and wanted to konw what each one ended up as you could.
Ok, one possible solution is when the iSCSI Template structure gets
registered with the iSCSI Transport, the LLD can tell the transport what
values are already defined. I think this point really goes back to
previous points about different class attributes need to be dynamicly
registered within the iSCSI Stack when certain events occur.
I am not arguing with that. We sent a patch to break the session
stuff from the target (sfnet did not need the channel abstraction) and
from there to add a connection beneath it is a matter of getting hold
of the correct kobject to stick things under (when you use the
transport class/container stuff it is not as simple as before though).
We are also not using sysfs for creation anymore though. Maybe we need
to discuss that point too. We are using netlinks for this so
open-iscsi/linux-iscsi/whatever-name-it-is-called-today:) and pyx have some
confliting points.
As far as filesystem based creation stuff goes it also seems our sysfs
masters may prefer configfs for things like software iscsi, dm or bonding
where userspace is driving the device creation and not the kernel. Do
the scsi maintainers care about this?
Considering the following:
1) iscsi_attach_transport() is called when the iSCSI Stack is loaded:
/sys/class/iscsi_transport/
a) Initiator[Name,Alias] is not set.
The stack will set this value later.
b) Initiator[Name,Alais] is set.
Assume that ->get_initiator_[name,alias]() will return
values from hardware
this is unrelated to sysfs or netlinks, but will this be able
to support two stacks running at the same time with different
initiator names? It looks like it will be shared across
drivers so it would need
/sys/class/iscsi_transport%SOME_STACK_ENUM
I am jsut wondering becuase whether we should use one name for all drivers
vs each driver using its own has come up several times on the sfnet 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
