Hi Martin, Apologies for the delayed response . >Interesting idea. Are you aware of a technology for non-FC transports that could take the role of FPIN? I have to admit I'm not, but that doesn't mean they don't exist or won't exist in the future. .... ... >If we want to modularize this, we need a *generic* event listener thread. A module would basically provide an fd for that thread to poll on, and a callback to be called when an event occurs. This idea appeals to me a lot, in particular because we already have an event listener (the uevent listener thread) >which is sitting idle most of the time. >So Muneendra, instead of creating a new receiver thread, you would extend the existing uevent listener to handle the FPIN events as well. >The thread would now add uevents to the uevent list and FPIN events to the FPIN events list. [Muneendra] Could you please refer to my query below .... .... .... >One word of caution here: we must be careful not to over-engineer. >As long as no other mechanism like FPIN for other transports is conceivable, generalizing the concept makes only so much sense. >Therefore we shouldn't hold back the FPIN patches until we have conceived of a generic mechanism, which may take a lot of time to develop. If another mechanism becomes available, we could still try to generalize the concept, if we keep the current additions clean and well-separated from the core >multipathd code. >However I am really thrilled by the prospect of generalizing event handling and reusing the uevent threads for FPIN. That would reduce complexity a lot, which is a good thing IMO. I have a query with respect to generalizing event handling and reusing the uevent threads . Please correct me if iam wrong. FPIN events work on NETLINK_SCSITRANSPORT netlink_kernel_create(&init_net, NETLINK_SCSITRANSPORT, &cfg); ==>scsi_netlink.c whereas uvents works on NETLINK_KOBJECT_UEVENT. netlink_kernel_create(net, NETLINK_KOBJECT_UEVENT, &cfg); ==>kobject_uevent.c I am not sure whether we can reuse the uevent threads for both uevents and fpin events. In case if my understanding is wrong could you please clarify on the same. Best Martin -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
