Erez Zilber wrote:
> When a transport (e.g. iscsi_tcp, ib_iser) is unloaded, a notification
> must be sent to userspace. This will allow the userspace code to release
> all transport related resources.
>
Thanks for fixing this.
> +
> struct iscsi_uevent {
> uint32_t type; /* k/u events type */
> uint32_t iferror; /* carries interface or resource errors */
> @@ -187,6 +190,9 @@ struct iscsi_uevent {
> struct msg_transport_connect_ret {
> uint64_t handle;
> } ep_connect_ret;
> + struct msg_trans_error {
> + char name[ISCSI_TRANSPORT_NAME_MAXLEN];
> + } trans_error;
iscsi_trans_error sets the transport_handle, and iscsid works with the
handles when talking to the kernel. You could have just done search by
free_transport_by_handle in iscsid. Are you passing the name because it
feels nicer or was there some other reason? We might want to stay
consistent in what we talk to the kernel with.
If you are going to ask about the handle, I have no idea why we just did
not always use the name instead of a handle based on the pointer to the
transport struct. I think it was because originally long long ago, we
actually referenced the handle (that is instead of doing the loop and
match in iscsi_if_transport_lookup) passed down from userspace which was
dangerous and of course deadly for the case where the transport module
got unloaded :(
Also I think you want to iscsi_trans_error when
iscsi_if_transport_lookup() fails. The lookup will fail if iscsid passes
us a bad handle. Or if we do not want to add those calls then we
probably want to rename the functions and event to indicate it is just
for transport unloading/removal.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
