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
-~----------~----~----~----~------~----~------~--~---

Reply via email to