On 11/08/2012 05:32 PM, Andy Grover wrote: > Hi Mike and everybody, > > The Red Hat packaging of open-iscsi (iscsi-initiator-utils) has > contained C and Python libraries for open-iscsi since 2009. These have > been used only by the Anaconda installer, and haven't been pushed upstream. >
Have you reviewed the lib yourself and what do you think it needs? Not putting you on the spot. Just want to know where we are starting from. I just briefly looked at the code and was not sure what has changed since I last worked on it. My issue was that it was nice for what we used it for in RHEL/fedora, but it needs some updating. It is based on a confusing open-iscsi'ism where the node is actually a portal. And actually it represents more. It is more like a set of objects (target, portal, initiator/initiator-port) to create N sessions with. We should define a lib that is more based on the iscsi RFC and how it is implemented in linux and the iscsi ima lib (at least make it so vendors using IMA can use our lib so they do not have to call iscsiadm or modify iscsiadm in weird ways). Fix the definition of a node/target, portal, etc so it is not defined as a result of the crustiness of the tools and how they grew over time. I would like the iscsi tools to be able to use the iscsi lib's exported API. Almost everything iscsiadm wants to do, other tools wants to do too. I am not sure if this a hard requirement though. However, the current way that the tools and lib are built is not nice. It is too fragile to changes in the code that is shared. I think you also need to update the libiscsi_network_config struct or redfine it so it handles vlans, ipv6 settings and the tcp/net options qlogic has been posting about, and whatever else is missing or define the interface in a way that we can easily update it while maintaining compat. I think libiscsi_set_netconfig is the wrong. It assumes that the net config is done in the kernel. It can be done in kernel for qla4xxx/be2iscsi, but is done by a combo of iscsiuio/kernel in bnx2i and for cxgb*i it is iscsid/kernel. We could have a call that passes data directly to the kernel for testing or other developer reasons, but it should not be named something generic like libiscsi_set_netconfig. We should have a generic call to config networking for the cards, so apps do not have to know the implementation details. libiscsi_get_firmware_initiator_name is based on the assumption that there is only 1 ibft initiator. We can do boot through multiple cards/ports and they can have different initiator names. libiscsi_discover_sendtargets_by_hwaddr and libiscsi_discover_sendtargets is sort of weird. The former only supports be2iscsi/qla4xx and the latter only supports software iscsi. We are missing bnx2i/cxgb*i/iser. I also do not think the caller should have to know the implementation details for what function to call. For software iscsi we would also want to handle when they user wants to do iface binding. When I was working on the lib I wanted to rewrite the tools. They have got really crusty due to trying to maintain compat (the sysfs and idbm code are crazy). They were also written when we did not know how all iscsi hw would work and we were basically wrong at every point :) I think maybe starting by specifying the objects we want to manage and get info about and what we want to do with those objects would be best??? -- 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?hl=en.
