Eli Dorfman wrote: >>> Doron Shoham wrote: >>>>> Hi Mike, >>>>> Are you ok with this patch? >>>>> >>>> I think so. There was just some minor things I was going to fix when I >>>> merged it . For exmaples the timer values are not picked up right away >>>> so they need to be attr deffered. >>>> >>>> I am not going to merge it for the next release (the one that is in rc >>>> now), because some apps (installers and mkinitrd type of tools) are not >>>> ready for the -f flag and it is too late to change them. >>>> >>>> So I will do a branch for the next release or merge this first when I >>>> make the new release. I was just waiting to see if Hannes fixes the >>>> Makefile patch he had. >>> Hi, >>> >>> Did you meant open-iscsi-2.0-869.1 as the next release? >> The dot releases are just bug fixes. >> >>> If not, can you estimate in what release it will be merged? >>> >> 870. > > Isn't this patch a bug fix as well? For example, changing transport > name while session is active, leaves stale session entry.
It fixes your bug, but like I said it adds a new problem. If you can figure out a fix that does not add a regression then I can merge it sooner. Your problem also does not exist in git because of the transport_name changes, but I do not like that code for the reasons Pete and I discussed in the other thread and because that breaks existing iser users. We could avoid the iser breakage by fixing iscsi_discovery again, but 869 broke the node.transport support and I do not think that was right to do to distros that were using iscsiadm. And we are going to have other drivers needing to set the transport_name so we need a proper solution to this that we are going to support like other commands. In the end what we need is something that is going to be usable by tools like the distro installers, so that when a user goes to install to a iscsi disk the proper modules get setup or if we want to switch modules we can. And it has to be simple enough that normal users can just use it. If we want to say use iscsi_discovery then we can do that, but that interface has to be made stable so distros can use it - except for the transport_name mess up I have been adding compat code to iscsiadm. So for the installers if we have the user enter the target info, then it runs iscsi_discovery to figure out what module to use, I think that could work. The only problem might be what to do if you have multiple modules that work. Maybe we could make records for all modules, or ask the user which one they wanted to use. OTOH, if we do not use iscsi_discovery then we could just have the user enter in the module to use with the target info (this is what I was thinking when I did the default iser and bnx iface code). I do not know what is best, but what we are doing today does not seem nice. > Can't you merge it to the nearest release? > If not, when do you plan to release the 870? It's done when it is done :) I wanted to try and get it out when .26 is out because the modules in the tarball releases do not work with that kernel. Also the sysfs code was broken when sysfs compat was not used and in newer kernels that do not have block device symlinks from the scsi_device. So if you want to help you can: 1. Take the kernel modules from upstream 2.6.26-rc4 and update the kernel modules in the open-iscsi git tree to them, and then update the compat patches to apply over the new modules. 2. The sysfs code is now fixed in git. It needs testing for all the kernel combos we support. Checkout the kernels we support and then check to see if when sysfs compat is on or off, if iscsiadm/iscsid works. 3. Remove the default ifaces code with something better. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
